[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gnulib] localtime_r thread-safe?
From: |
Paul Eggert |
Subject: |
Re: [bug-gnulib] localtime_r thread-safe? |
Date: |
Thu, 04 May 2006 11:05:10 -0700 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
Bruno Haible <address@hidden> writes:
> Since I cannot see how a function can return a pointer and an int
> simultaneously,
It can't. If you want the old, incompatible (DCE) localtime_r under
HP-UX, you're supposed to link with the DCE library and compile with
-D_PTHREADS_DRAFT4. But anyone who wants the DCE localtime_r won't
want gnulib localtime_r anyway, so this shouldn't be a problem.
> and since I've no idea when _PTHREADS_DRAFT4 is defined, I wouldn't
> trust the system's localtime_r function here.
Our existing check will already reject any misconfigured build that
defines _PTHREADS_DRAFT4 and therefore gets the wrong prototype. So I
don't see the danger here.
The only problem that I can see is that you need to use the right
macros defined to get the system headers to define localtime_r under
HP-UX. We should put that into gl_TIME_R, if it isn't there already.
>> If there's a specific system where this global-lock workaround is
>> actually needed
>
> Any other system where the localtime_r test fails, when GNU Pth is installed.
But GNU Pth uses strictly non-preemptive scheduling, right? So I
don't see the problem; surely gnulib localtime_r won't be preempted.
(Disclaimer: I've never used GNU Pth.)