> > > 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" respo
ave Page
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Win32 Thread safetyness
> >
> >
> > Well, actually I tried to run configure --enable-thread-safety on a
> > MinGW platform and got:
> >
> > configure: error: pthread.h n
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 28 August 2005 22:56
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Win32 Thread safetyness
>
>
> Well, actually I tried to run configure --enable
Tom Lane wrote:
> Bruce Momjian writes:
> > Magnus Hagander wrote:
> >>> Also, there doesn't seem to be a good way for users to know
> >>> if libpq or ecpg was compiled to be thread-safe.
> >>
> >> Right. A runtime function for this might be a good thing? Like "bool
> >> PQisThreadSafe()" or suc
Dave Page wrote:
> > So, we might be able to get away without this on Win32, or perhaps the
> > pthread_self().p is a valid unique identifier for Win32 threads and
> > pthreads.
>
> Right.
>
> > How is this pthread_self() call working on Win32 now? Is pthreads a
> > requirement for libpq threadi
Bruce Momjian writes:
> Magnus Hagander wrote:
>>> Also, there doesn't seem to be a good way for users to know
>>> if libpq or ecpg was compiled to be thread-safe.
>>
>> Right. A runtime function for this might be a good thing? Like "bool
>> PQisThreadSafe()" or such?
> Yes, and a flag to ecpg.
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 28 August 2005 18:19
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Win32 Thread safetyness
>
>
> I poked around this one. The SSL locking docum
Magnus Hagander wrote:
> > The basic issue with SSL is that it wants some unique
> > identifier for threads. They really should have defined the
> > function to take pthread_t rather than unsigned long because
> > pthreads doesn't really give us a useful way to get an
>
> They absolutely shou
> The basic issue with SSL is that it wants some unique
> identifier for threads. They really should have defined the
> function to take pthread_t rather than unsigned long because
> pthreads doesn't really give us a useful way to get an
They absolutely should not have done that. That would'v
I poked around this one. The SSL locking documentation is at:
http://www.die.net/doc/linux/man/man3/crypto_set_id_callback.3.html
The description isn't clear. When they talk about locking_function()
and id_function(void), they are talking about arguments to the SSL
functions listed above, no
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 25 August 2005 16:35
> To: Magnus Hagander
> Cc: Dave Page; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Win32 Thread safetyness
>
> "Magnus Hagander" <[EMAIL PRO
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Yuck. This sucks :-( I was very much hoping we could avoid an other
> build *and* runtime dependency. Which will be a cascading runtime
> dependency to each and every program that uses libpq. double-:-(
That seems like a clear nonstarter :-(
Can we
> Unfortunately I just found that we still cannot build in
> thread safety mode on Windows, due to an error on my part -
> specifically, I concentrated on libpq, not realising that
> ecpglib is also thread aware.
>
> It seems that ecpglib uses far more of pthreads than libpq
> does, so our min
On 2005-08-24, "Dave Page" wrote:
> Which relates to:
>
> static unsigned long
> pq_threadidcallback(void)
> {
> return (unsigned long) pthread_self();
> }
This is an abuse of pthread_t - it is explicitly not guaranteed in the spec
that pthread_t is an integer type, or even a scalar type; it'
Unfortunately I just found that we still cannot build in thread safety
mode on Windows, due to an error on my part - specifically, I
concentrated on libpq, not realising that ecpglib is also thread aware.
It seems that ecpglib uses far more of pthreads than libpq does, so our
mini implementation u
15 matches
Mail list logo
