I've been looking into fixing the --enable-thread-safety option on
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
however this should be easy to fix (properly) for someone more
with Make than I am.
Thread safety cannot currently be enabled through configure on Windows
two reasons however:
- If the POSIX Signals test fails, configure fails. We have our own
code on Windows, so it's no surprise that configure fails this test.
is easily fixed with the addition of ' -a "$PORTNAME" != "win32"' to
test at line 1179 of configure.in. Why are signals needed for thread
- The thread_test program fails to even compile on Windows.
This second problem is the main issue, the main point being that our
emulation doesn't implement enough of the API for the test program to
only that that's needed for libpq. To fix this we must either convert it
use Windows threads, use a full implementation of the pthread library,
implement more of the API ourselves. the first option will obviously
some effort, and probably be best implemented as a Windows specific
the test program. The second introduces extra dependencies, at worst at
best just build time. The third is also additional, potentially
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
apps are the standard on Windows, I don't suppose this is likely to
future releases. It therefore seems to me that the sensible course of
is to skip the thread test altogether on Windows.
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2005-07-21 14:03:53|
|Subject: Re: recover corrupted pg_controldata from WAL |
|Previous:||From: Bruce Momjian||Date: 2005-07-21 13:39:38|
|Subject: Imprecision of DAYS_PER_MONTH|