Re: thread safety.
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: thread safety.
- From: George Neill <georgen@...>
- Date: 2009年6月12日 03:29:17 -0500
Asko,
On Thu, Jun 11, 2009 at 11:54 PM, Asko Kauppi<askok@dnainternet.net> wrote:
>
> The re-entrant gmtime_r() and localtime_r() are not ANSI C, I believe. You
> can provide a patch but inclusion of non-ANSI C features has seemed to be a
> 'no'. Maybe this will change, eventually.
>
> "The asctime_r(), ctime_r(), gmtime_r(), and localtime_r() functions are
> expected to conform to ISO/IEC 9945-1:1996 (``POSIX.1'')"
right, indeed gmtime_r/localtime_r would fall under LUA_USE_POSIX
from solaris localtime manpage,
The asctime(), ctime(), gmtime(), and localtime() functions
are safe to use in multithread applications because they
employ thread-specific data. However, their use is
discouraged because standards do not require them to be
from linux (ubuntu) localtime manpage,
The four functions asctime(), ctime(), gmtime() and localtime() return
a pointer to static data and hence are not thread-safe. Thread-safe
versions asctime_r(), ctime_r(), gmtime_r() and localtime_r() are spec‐
ified by SUSv2, and available since libc 5.2.5.
so gmtime/localtime are not required to be thread-safe by the standard
... but some vendors have made them thread-safe.
> Can you post a case where using such functions really presents a hazard, in
> a multithreaded application?
of course, I will try to put together an example that breaks for you.
The idea would be to have two or more threads with their own lua
state; and at the same time, have one writing to the static data the
other reading from it.
> Why do you think 'system' is a problem? Maybe it's been on the warning list
> because when you launch external programs, there's no guarantee how
> multithread unfriendly they could be? I find no problem with 'system()'
> itself.
from solaris system(3c) man page,
The system() function manipulates the signal handlers for
SIGINT, SIGQUIT, and SIGCHLD. It is therefore not safe to
call system() in a multithreaded process, since some other
thread that manipulates these signal handlers and a thread
that concurrently calls system() can interfere with each
other in a destructive manner. If, however, no such other
thread is active, system() can safely be called concurrently
from multiple threads. See popen(3C) for an alternative to
system() that is thread-safe.
they suggest,
int my_system(const char *cmd)
{
FILE *p;
if ((p = popen(cmd, "w")) == NULL)
return (-1);
return (pclose(p));
}
as a system() alternative.
Thanks,
George.