On Wed, 12 May 2004, Larry Rosenman wrote:
>
>
> --On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane <tgl@sss.pgh.pa.us>
> wrote:
>
> > Larry Rosenman <ler@lerctr.org> writes:
> >> --On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane
> >> <tgl@sss.pgh.pa.us>=20 wrote:
> >>> At this point I'd settle for saying that --enable-thread-safety on
> >>> Unixware will generate a library that requires -Kpthread. This is
> >>> kinda grungy but it seems that any more-pleasant solution would
> >>> require a disproportionate amount of work.
> >
> >> If I did the work for the dlsym() stuff would you and the rest of core@
> >> accept it?
> >
> > How invasive a change are we talking about? I'd be inclined to reject a
> > patch that makes libpq materially less readable ...
> >
> > regards, tom lane
> I was thinking of pq_pthread_* calls, and that function would
> set a static flag for calling either the real pthread_* function
> or a statically named version in libpgport.a that is a single thread
> wrapper.
>
> I know, this sucks, but, I don't see any other way, other than linking
> *ALL* libpq-using programs (including initdb and friends) with -K pthread.
k, a change that 'sucks', vs linking against -Kpthread ... I'm for the
-Kpthread route myself, which still sounds the 'clean' solution ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
