Fwd: Re: thread safety.

[Bulat Ziganshin]

the follwoing message forwarded from Lua list and says about non
thread-safety of *time and system calls. it may be useful for haskell
libs developers


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===============
Asko,

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()'
> 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.

===8<===========End of original message text===========



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com