Easiest way to support Windows coming from Linux/Mac?

[mvk]

Congratulations.
I see one potential problem though. I would stay away from using TerminateThread as it's considered unsafe (last resort).

I think pthread_join also waits for the thread to terminate the natural way (i.e. exiting threadproc)

So I'd either remove TerminateThread completely or,
if you need to terminate before the sleep is over, I suggest to encapsulate WinAPI Event (=pthread mutex + condition variable) in alarm struct.
CreateEvent returns handle (that needs to be Close()d later), so manual reset, initially non-signalled

Then instead of using Sleep(msec) you would use WaitForSingleObject(StopEvent, msec)
and SetEvent(StopEvent) instead of TerminateThread

Ok thanks. I will have to look into it. It is to be expected that things are not optimal on first try.

In this case, the terminate is for the alarm thread, because you don't know if this thread has fired or is still sleeping. (The alarm thread does nothing but sleep, then change a variable and exit, and is created for every search). I will study your suggestion.

I now see that the corresponding posix version can't be right, because the join will not return until the alarm has fired, and this is not what I want.

[jdart]

If you use C++ 11 you do not need Boost, IMO.

C++ 11 has most of the portability constructs you need, especially for threading.

--Jon

[mvk]

If you use C++ 11 you do not need Boost, IMO.

C++ 11 has most of the portability constructs you need, especially for threading.

I think it is working ok now on both win32 and posix using own mapping to native calls from C. Either Event or mutex+cond. Exe download is here and source is on github. Only thing missing is pondering. I will let it play tomorrow in HGM's tourney as a weak fun engine running under wine. Maybe add null move pruning tomorrow. In a sense this is a formal successor of my old mscp.