Re: [bug-gnulib] localtime_r thread-safe?

[Paul Eggert]

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.)