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

Поиск
Список
Период
Сортировка
От Philip Yarra
Тема Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Дата
Msg-id 200309101207.42202.philip@utiba.com
обсуждение исходный текст
Ответ на Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nico King
Дата:
Сообщение: Re: Temp tables and copy
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: plpgsql doesn't coerce boolean expressions to boolean