Re: [Bug-gnubg] MS Windows / Multi-Threading / Code simplification

[Superfly Jon]

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 <address@hidden> 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