From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Magnus Hagander" <mha(at)sollentuna(dot)net> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Win32 Thread safetyness |
Date: | 2005-08-25 20:19:39 |
Message-ID: | E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC9C8A@ratbert.vale-housing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 25 August 2005 16:35
> To: Magnus Hagander
> Cc: Dave Page; pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] Win32 Thread safetyness
>
> "Magnus Hagander" <mha(at)sollentuna(dot)net> 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 confine the damage to stuff that uses ecpg, rather
> than adding a
> dependency to everything that uses libpq?
Yeah, that could be done with a little makefile hacking - we can use our
emulation for libpq and normal pthreads for ecpglib.
However, I'm still unsure how to handle the problem I posted about. From
what Andrew Supernews has posted about pthread_t not being guaranteed to
be an int, the appropriate fix would be to stop casting it to long. I
haven't looked at the implications of that yet though - any thoughts
before I do?
Regards, Dave.
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-08-25 20:23:50 | Re: Stuff running slooow |
Previous Message | Joshua D. Drake | 2005-08-25 20:18:10 | Re: Stuff running slooow |