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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]