From: | Philip Yarra <philip(at)utiba(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | ohp(at)pyrenet(dot)fr, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) |
Date: | 2003-09-10 02:07:42 |
Message-ID: | 200309101207.42202.philip@utiba.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
> I see --- looks bad ---- failures below for OSF, Solaris, and FreeBSD
> below.
Actually, I am not sure the OSF failure is correctly reported... your test app
had me a little baffled in that case.
> We would have to get some thread mutex, make the function call, copy the
> return values into the passed pointer, and release the mutex? Do we
> test to see if we are in thread mode before doing the locking? Is that
> test even possible or desirable?
I guess as with the threading stuff in ECPG:
#ifdef SOME_DEF (sorry, have to check the ECPG source on that one)
pthread_mutex_lock(&my_mutex)
#endif
/* do stuff */
#ifdef SOME_DEF
pthread_mutex_unlock(&my_mutex)
#endif
> Seems we will need to rename the config variable to be
> NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each
> *_r function, and fall back to the mutex if both settings are false.
Yeah, or you could just always use the wrapper and not try to do all the test
in configure... doubtless less efficient, but maybe better for the mental
health...
> This part has me concerned too:
> > Copying the struct hostent does not suffice, since it contains
> > pointers - a deep copy is required.
>
> Would someone with thread mutex experience assist me?
Ummm... replace /* do stuff /* above with a deep copy of the hostent struct.
I'll give that a shot if you like.
Regards, Philip.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-09-10 02:29:17 | Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) |
Previous Message | Jan Wieck | 2003-09-10 01:56:31 | Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean |