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

Re: Win32 Thread safetyness

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Win32 Thread safetyness
Date: 2005-08-29 15:18:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > > Yes, and a flag to ecpg.  Added to TODO:
> > 
> > Um, it's not clear *when* you need to know this:
> > 	- application configure time?
> > 	- application compile time?
> > 	- application link time?
> > 	- application run time?
> > 
> > Of those possibilities, "add a function" responds to only one, and 
> > it's the one I can see least use-case for.  I should think that by 
> > run-time it's probably too late to do much about it other than fail.
> Yea, I am thinking a libpq function would say "libpq not thread-safe'
> and return an error.  I would think pg_config output would be 
> fine for any link or compile-time check.

Another idea might be to compile the library with a different name when
it's thread safe. And if your system supports it, we build both by
default. (libpq and libpqt or something). 


pgsql-hackers by date

Next:From: Mark WongDate: 2005-08-29 15:19:58
Subject: Re: Simplifying wal_sync_method
Previous:From: Tom LaneDate: 2005-08-29 15:13:29
Subject: Re: [HACKERS] Improved \df(+) in psql + backward-compatibility

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