Semaphores or Conditional Locks

[Osbios]

@Hiura:
Clang is now c++11 future complete in git:
https://github.com/llvm-mirror/clang/commit/e6e68b53778bb5a15c10a73a5bf18d8ab73f75e3


I'm currently trying to implement asynchronous background loading for OpenGL and just now was looking for Semaphores in SFML.

I like to queue work to threads (Like GLSL shader loading/compiling) and keep a steady frame rate in the main thread.
But OpenGL Context creation or activation in a new created thread is blocking my main thread to long. So I have a need for Semaphores to pause worker threads and let them continue to run on need. (Not completely creating/closing threads all the time may be better anyway)

I think this are needed basic functions until c++11 is mainstream and this is integrated by default.
Also I noticed that SFML doesn't have any sort of priority settings for threads.

SFML still can be a a beginner friendly 2D library but also a base for more advanced users.

@Laurent: If you disagree I'm carious if this has to do with your design goals for SFML or more with the implementation/maintenance of such features?

[Laurent]

C++11 is well supported by all the free compilers available on the market. And if you want to stick to C++03 for some reason (there are valid reasons, otherwise SFML would already have switched ), there are many good libraries dedicated to threading.

SFML implements threading because it needs it, not to reinvent the wheel.

And by the way, reinventing the wheel can be an option here, since you just have to wrap 3 very simple OS specific functions.

[Tank]

I don't think it's a priority to hurry and make SFML not work anymore for gcc 3 or VC++ 9 users.

It's definitely not a priority, because C++11 is downwards-compatible. So indeed there's nothing stopping you from not switching at all. But I still don't know why one should stick to GCC3 or an older VC++ version. And because of this:

And if you want to stick to C++03 for some reason (there are valid reasons, otherwise SFML would already have switched )

I'm really interested in the concrete reasons. I tried to think of some myself but couldn't find any.

Btw.: I'm fine with SFML supporting C++03, because it does not influence _my_ code at all, I'm just interested what reasons exist that make people stay with an older version. Because I was endless happy not having to include Boost everywhere just for some features that are included in C++11 now.

[Laurent]

The reasons are mainly about Visual Studio. Some people may use SFML at work, where they are stuck with VS2005 or 2008 because of strict software policies or budget limitations. Others may have a VS2008 Professional version (thanks to a student program or whatever), and cannot get the newer equivalents. There are free versions of the IDE but they lack important tools, and the whole extension system.

Other than that, I think it's ok to force users to live with C++11. In a first step I'll integrate C++11 features conditionally, without breaking C++03 compatibility, and then, in 2 or 3 years maybe, I'll probably switch to C++11-only for the new design of SFML 3

[Tank]

I see, thanks for pointing it out.

In a first step I'll integrate C++11 features conditionally, without breaking C++03 compatibility,

Sounds like an ok solution to me.