I did write this code and at the time using the windows code directly was quicker on windows and there were some bugs in the glib threading code on windows.
I expect glib threading support is much better on windows now so removing the windows code makes sense (especially if it doesn't work anymore!). I also notice some checks/two lots of code, if GLIB 2.32 is available. I would suggest removing those too (which would imply you can only compile with multiple thread support if you have a new enough version of Glib). Jon On 16 January 2015 at 00:03, Michael Petch <mpe...@gnubg.org> wrote: > Howdy all, > > Most aren't aware of this, but on MS Windows we support two types of > threading - Win32 Native threading and GLIB threading. For quite some > time (years) I have been using GLIB threading when doing official builds > on MS Windows. GLIB ultimately calls the Win32 native API under the > hood) I discovered the past few days that Win32 threading is actually > broken. > > Since it is broken we can opt to spend time fixing it or remove the > Win32 thread option altogether, so we have a choice between No > threads/GLIB threads. This in turn simplifies the threading code from a > maintenance perspective. > > Our project requires GLIB to build, and GLIB and its threading module do > work (to my knowledge) under MSVC (Microsoft's C++). > > Does anyone have a reason to support Win32 threads that I may be unaware > of? I am specifically CC'ing Jon Kinsey because I believe he does > Windows builds (or did) using MSVC tool chain. > > Thanks, > -- > Michael Petch > GNU Backgammon Maintainer / Developer > OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304 >
_______________________________________________ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
