From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Win32 Thread safetyness |
Date: | 2005-08-25 08:03:27 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE6C7912@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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 used in libpq just won't cut
> it. I've bitten the bullet (well, more of a jelly bean
> actually) and started rewriting things to use the official
> win32 pthreads library, however I ran into an error that I'm
> not sure about:
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-:-(
Anyway, one other concern: Do we *know* how this will interact with
win32 native threads? Meaning will a libpq built against the pthreads
library be safe for *native threads*. Because you can definitly expect
most of the win32 apps that need thread-safeness to be usign native
threads - I've so far not come across a single program that's native
win32 that uses pthreads, whereas almost every program written uses
native threads (though most often not in a way that would need a
threadsafe libpq)
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2005-08-25 08:31:17 | Re: [HACKERS] Proposed patch to getaddrinfo.c to support |
Previous Message | Magnus Hagander | 2005-08-25 07:58:21 | Re: Stuff running slooow |