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 #