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 To: Lua list 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 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@gmail.com