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 Fri, 31 May 2013 21:12:07 GMT
Chuck,

On 5/31/13 4:42 PM, Caldarale, Charles R wrote:
>> From: Rainer Jung [mailto:rainer.jung@kippdata.de] 
>> Subject: Re: APR/native errors with non-blocking I/O
> 
>> Compile and have fun.
> 
> Or we could talk about Mark's familiarity with C :-)
> 
>> IMHO we don't have that in the code to output text instead of cryptic
>> numbers because it isn't really available on all needed platforms. I
>> could be wrong though.
> 
> The strerror() API is part of the POSIX and C standards, so it should
> be there unless you're running on some cut-down embedded platform.
> However, it is not thread-safe, so it might not be appropriate to
> include it in JNI code.

I'm pretty sure that sterror is thread safe: it should just return a
static char*. The GNU man page for strerror() says that strerror_r is
just like strerror(), "but is thread safe". It doesn't specifically say
that strerror() is *not* thread-safe, but does imply it.

On my Mac, there is no mention of thread safety at all on that man page
(except this: "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.)

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.

-chris


Mime
View raw message