LaurentGomila/SFML — pull request #640 by zsbzsb (2014-06-19 22:45:57+00:00)
Title: Added function to free hidden internal SFML context to avoid memory leak

After working on a memory leak in SFML.NET I have narrowed the issue down to SFML creating many contexts that are never destroyed. The following code example is enough to cause SFML to create contexts and leak memory.

```
#include

#include

void ThreadEntry()
{
sf::Context();
}
int main()
{
sf::Context mainThreadContext;
while (true)
{
std::thread(&ThreadEntry).join();
}
}
```

Per the following thread, @LaurentGomila explains that SFML internally creates a hidden internal context for each thread that touches any of SFML functions that require a valid GL context. As you continue reading the thread, a suggestion was to add a public function called "releaseThreadContext" to release this internal context. This is what this PR does.

http://en.sfml-dev.org/forums/index.php?topic=10309.msg70990#msg70990

Now, just for kicks I followed up another thread post made by @binary1248.

http://en.sfml-dev.org/forums/index.php?topic=13568.msg95089#msg95089

The code example here is to show that it possible that memory leaks may also come from the video driver. I tested the example code and it does not leak, it also does not leak for @rcurtis (whom also experienced the memory leak with SFML not freeing contexts).

This pull request only adds a single public function ```sf::Context::releaseThreadContext()```. After modifying the above example code to the following all memory leaks are gone.

```
#include

#include

void ThreadEntry()
{
sf::Context();
sf::Context::releaseThreadContext();
}
int main()
{
sf::Context mainThreadContext;
while (true)
{
std::thread(&ThreadEntry).join();
}
}
```