tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: APR/native errors with non-blocking I/O
Date Mon, 03 Jun 2013 14:32:29 GMT
Chuck,

On 5/31/13 5:46 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
>> Subject: Re: APR/native errors with non-blocking I/O
> 
>> I'm pretty sure that sterror is thread safe: it should just return a
>> static char*.
> 
> Would that it were that simple.  Seriously, it's not thread safe; a
> second thread calling the API can overlay a prior thread's message.
> If it were thread safe, GNU wouldn't have bothered with the _r
> alternative.
> 
>> "For unknown error numbers, the strerror() function will return its 
>> result in a static buffer which may be overwritten by subsequent calls."
>> Hopefully, that means static and private to the thread, but I don't know.
> 
> Nope, it's static and global.

:(

>> Back to the GNU man page, it says: "strerror()  is specified by
>> POSIX.1-2001, C89, C99.  strerror_r() is specified by POSIX.1-2001.", so
>> we may be able to rely upon it.
> 
> Yes, the _r alternative is available on many (probably most, these
> days) platforms, but it's by no means universal.  (On another mailing
> list, we had someone still trying to use gcc 3.3...)

Can 'configure' figure out if strerror_r is available? I have no idea
how it works its magic.

-chris


Mime
View raw message