Re: --enable-thread-safety on Win32

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: --enable-thread-safety on Win32
Date: 2005-07-27 20:52:08
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC959B@ratbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Did anyone get a chance to think about this? I'd like to fix this for
8.1, but it should also make life easy with the new libpq based ODBC
driver improvements if I can produce an appropriate patch sooner rather
than later!

Regards, Dave.

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Dave Page
> Sent: 21 July 2005 15:00
> To: PostgreSQL-development
> Subject: [HACKERS] --enable-thread-safety on Win32
>
> 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martín Marqués 2005-07-27 21:05:26 Re: Integrated autovacuum
Previous Message Josh Berkus 2005-07-27 20:30:01 wal_buffer tests in