Re: threads stuff/UnixWare
От | Marc G. Fournier |
---|---|
Тема | Re: threads stuff/UnixWare |
Дата | |
Msg-id | 20040512172635.C35531@ganymede.hub.org обсуждение исходный текст |
Ответ на | Re: threads stuff/UnixWare (Larry Rosenman <ler@lerctr.org>) |
Ответы |
Re: threads stuff/UnixWare
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: