Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)

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.

In response to

Responses

Browse pgsql-hackers by date

  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