Re: thread safety tests

On 6/9/2004 9:36 AM, Bruce Momjian wrote:

> Jan Wieck wrote:
>> I am wondering why thread_test.c is checking for mktemp()? That function 
>> is nowhere used in the libpq.
> 
> Uh, it isn't checking for mktemp, it is using it, and it is using it
> because someone didn't like hard-coded paths I was using in the past. 
> Is there something wrong with using mktemp?  I have heard of no
> portability problems, except some need six X's, and we updated that.

There seems to be a portability issue here. Stefan Kaltenbrunner 
reported a configure failure on sparc64-unknown-openbsd3.5 and the 
config.log says:

/tmp//ccx22029.o: In function `main':
/tmp//ccx22029.o(.text+0x8c): warning: mktemp() possibly used unsafely; 
consider using mkstemp()

Which is only a warning at this time, it fails later on getpwuid().


Jan

> 
>> Also, I would suggest that we allow to build the libpq with thread 
>> specific compiler options, even if it is not entirely thread safe. It 
>> would require that a really multithreaded application has to have 
>> mutexes around certain operations, but being entirely unable to 
>> configure in a way that adds thread compile options to the CFLAGS makes 
>> libpq completely useless for multithreaded programs on some platforms 
>> (for example Solaris).
> 
> I am confused what you are suggesting.  Are you saying to use thread
> flags but not the other things that make is thread-safe?  There isn't
> much else other than the flags actually.  Now that more OS's are
> thread-safe by default, we could consider using threading if it is
> available by default.  We would need some way of reporting that to the
> user, perhaps via an installed readme file or a pg_config output option.
> 


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #