Fwd: Re: thread safety.
bulat.ziganshin at gmail.com
Fri Jun 12 05:22:12 EDT 2009
the follwoing message forwarded from Lua list and says about non
thread-safety of *time and system calls. it may be useful for haskell
This is a forwarded message
From: George Neill <georgen at neillnet.com>
To: Lua list <lua at bazar2.conectiva.com.br>
Date: Friday, June 12, 2009, 12:29:17 PM
Subject: thread safety.
===8<==============Original message text===============
On Thu, Jun 11, 2009 at 11:54 PM, Asko Kauppi<askok at 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()'
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.
int my_system(const char *cmd)
if ((p = popen(cmd, "w")) == NULL)
as a system() alternative.
===8<===========End of original message text===========
Bulat mailto:Bulat.Ziganshin at gmail.com
More information about the Libraries