Skip site navigation (1) Skip section navigation (2)

Re: --enable-thread-safety on Win32

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: --enable-thread-safety on Win32
Date: 2005-07-28 01:39:01
Message-ID: 200507280139.j6S1d1X14781@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Dave Page wrote:
> 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!

I have thought about it and it needs to be addressed before 8.1 final,
but I don't have time at the moment.

---------------------------------------------------------------------------


> 
> 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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers by date

Next:From: Neil ConwayDate: 2005-07-28 01:40:52
Subject: Re: Some new list.c primitives
Previous:From: Tom LaneDate: 2005-07-28 00:32:00
Subject: Re: Some new list.c primitives

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group