[Pachi] Pachi windows build

Paul paulsteyn1 at afrihost.co.za
Tue Jan 3 15:53:44 CET 2012

Hi Jukka,

> Hi Paul, nice to read someone also trying a Windows build. I joined
> the list today, to see if there's anyone working on a Visual Studio
> build.
I was also thinking of trying Visual Studio's compiler, but the chances
are that that will give more problams than MinGW, and won't solve any
of the problems I am having with MinGW, so it would only be out of
curiosity for me.

If we can both get this working, it will be nice to have HOWTOs for
building with either.

> There does exist InetNtop in Winsock, see here
> http://msdn.microsoft.com/en-us/library/windows/desktop/cc805843(v=VS.85).aspx
Yes, there is, but MinGW doesn't include it in their header files. This
means you should be able to rename it and have it build, but I'll have
to rewrite it, I think. Unless I can somehow build with MinGW and link
to the VS header files, but I don't think that is really a good

Does anybody out there know of any open source code to do this?

> As for nanosleep, there is no equivalent, and it's not possible to
> implement one on windows (in an ideal form).
Unfortunately I suspect you are right.

> I have seen some people abuse the Winsock select() call
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx
> to wait on a selector that is never triggered, and setting the desired
> sleep amount as the timeout parameter, which takes in
> nanosecond-precise values. Their assumption is that since you can pass
> in nanosecond-precise values, then select() would also sleep for
> nanosecond-precise times, but that is not accurate.
Sounds like a kludge that I'd rather avoid.

> It is possible to implement manual nanosecond-level-waits by
> busy-spin-waiting on a NOP loop and counting time manually with
> QueryPerformanceCounter & QueryPerformanceFrequency system calls, see
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx
> . The QueryPerformanceCounter is the highest-precision timer available
> on Windows (boils down to RDTSC, but implements consistency by not
> varying the frequency by power saver modes which lower the CPU bus
> speeds etc.) Although, since a thread can be pre-empted at any given
> time, such a spinwait sleep loop cannot guarantee to sleep exactly the
> desired time, and of course this will just waste system CPU resources.
Sounds like an even worse, and evil, kludge.

> This is because Windows
> does not allow sleeping a thread for such small time slices like
> nanoseconds. There's the Sleep function
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298(v=vs.85).aspx
> which is given a millisecond value, but it does not guarantee any
> precision, and in practice can have a large granularity, something
> like 2ms-15ms.
> ...
> Searching through the codebase, I see there's two calls to sleep,
> time_sleep(u->stats_delay); where stats_delay is set to 10ms by
> default, and time_sleep(TREE_BUSYWAIT_INTERVAL); where
> TREE_BUSYWAIT_INTERVAL == 100ms. Since the times are this high, I
> assume the actual times they get to sleep is not critical, and
> therefore the Sleep() system call is probably most appropriate.
I found this article (http://www.geisswerks.com/ryan/FAQS/timing.html)
talking about windows timing granularity. It seems like we can probably
use Sleep() as is, as you suggest, but we can increase the granularity
if required by using timeBeginPeriod() and timeEndPeriod(), provided we
don't need anything more accurate than 2 or 3 ms.

Maybe someone who knows this bit of Pachi code well can comment?

Thanks Jukka, it's nice to have someone else out there to bounce ideas


More information about the Pachi mailing list