This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Carlos O'Donell wrote:
That is not correct, tzset is MT-safe, and documented in the glibc manual as such.
Sorry, my use of the term "thread-safe" was incorrect. I was thinking of the problem of ensuring that a thread that calls localtime_r is insulated from another thread simultaneously calling tzset, i.e., that the tzset will appear to occur either all before or all after the localtime_r. As far as I know MT-Safe does not imply this sort of atomicity, so an application cannot assume it.
Having tzset be MT-safe will not slow down localtime_r
Wouldn't having tzset and localtime_r exclude each other slow down localtime_r? And if they don't exclude each other, shouldn't application writers avoid the abovementioned situation if they want localtime_r's results to be reliable?
Please bear with me here, as I'm by no means an expert on the various aspects of thread-safety in glibc.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |