I've been looking into fixing the --enable-thread-safety option on
Windows.
At the moment, we have some simple pthread emulation that may be used in
libpq if --enable-thread-safety is used. The Makefile is slightly
broken,
however this should be easy to fix (properly) for someone more
proficient
with Make than I am.
Thread safety cannot currently be enabled through configure on Windows
for
two reasons however:
- If the POSIX Signals test fails, configure fails. We have our own
signal code on Windows, so it's no surprise that configure fails this test.
This is easily fixed with the addition of ' -a "$PORTNAME" != "win32"' to
the test at line 1179 of configure.in. Why are signals needed for thread
safety anyway?
- The thread_test program fails to even compile on Windows.
This second problem is the main issue, the main point being that our
pthread
emulation doesn't implement enough of the API for the test program to
run,
only that that's needed for libpq. To fix this we must either convert it
to
use Windows threads, use a full implementation of the pthread library,
or
implement more of the API ourselves. the first option will obviously
take
some effort, and probably be best implemented as a Windows specific
version of
the test program. The second introduces extra dependencies, at worst at
runtime, at
best just build time. The third is also additional, potentially
significant
work.
However, fixing this issue using any of those methods seems somewhat
pointless. All the versions of Windows that we support are thread-safe
anyway (and this doesn't vary like it can on Unixes) and given that
threaded
apps are the standard on Windows, I don't suppose this is likely to
change in
future releases. It therefore seems to me that the sensible course of
action
is to skip the thread test altogether on Windows.
Sound reasonable?
Regards, Dave