Re: [webkit-changes] cvs commit: JavaScriptCore/pcre pcre.h pcre_compile.c pcre_exec.c
On Jan 6, 2006, at 3:51 PM, George Staikos wrote:
On Friday 06 January 2006 17:43, David wrote:
- tm t; - utc ? gmtime_r(&tv, &t) : localtime_r(&tv, &t); + tm t = *(utc ? gmtime(&tv) : localtime(&tv)); // We had an out of range year. Restore the year (plus/minus offset // found by calculating tm_year) and fix the week day calculation. if (realYearOffset != 0) { @@ -769,8 +779,7 @@ JSValue *DateObjectImp::callAsFunction(ExecState * /*exec*/, JSObject * /*thisObj*/, const List &/*args*/) { time_t t = time(0); - tm ts; - localtime_r(&t, &ts); + tm ts = *localtime(&t); return jsString(formatDate(ts) + " " + formatTime(ts)); }
@@ -899,8 +908,7 @@ // produce incorrect results, but there's no other option when calling localtime_r(). if (!utc) { time_t tval = mktime(t) + (time_t)((ms + yearOffset) / 1000); - struct tm t3; - localtime_r(&tval, &t3); + tm t3 = *localtime(&tval); t->tm_isdst = t3.tm_isdst; }
These look quite questionable to me. Is threadsafety not a goal anymore?
These calls are thread-safe on both Mac OS X and Windows -- both those platforms use per-thread globals for these calls. On Mac OS X, we also have the _r variants, but they are no more or less thread-safe (although it's more elegant to not use the globals). If there's an important platform that has the _r variants but a non- thread-safe localtime and gmtime we can add conditionally compiled code since Windows does not have the _r variants. -- Darin
On Jan 6, 2006, at 5:28 PM, Darin Adler wrote:
These calls are thread-safe on both Mac OS X and Windows -- both those platforms use per-thread globals for these calls.
On Mac OS X, we also have the _r variants, but they are no more or less thread-safe (although it's more elegant to not use the globals). If there's an important platform that has the _r variants but a non-thread-safe localtime and gmtime we can add conditionally compiled code since Windows does not have the _r variants.
These aren't threadsafe on Linux (Maks checked the glibc source code). And the _r variants are easy to implement in terms of the windows _s variants (or even in terms of the vanilla variants, given that they are threadsafe) on Windows. Looking at the OS X implementation the _r versions also look more efficient, though probably not enough to matter in the real world. Regards, Maciej
On Jan 7, 2006, at 8:50 PM, Maciej Stachowiak wrote:
On Jan 6, 2006, at 5:28 PM, Darin Adler wrote:
These calls are thread-safe on both Mac OS X and Windows -- both those platforms use per-thread globals for these calls.
On Mac OS X, we also have the _r variants, but they are no more or less thread-safe (although it's more elegant to not use the globals). If there's an important platform that has the _r variants but a non-thread-safe localtime and gmtime we can add conditionally compiled code since Windows does not have the _r variants.
These aren't threadsafe on Linux (Maks checked the glibc source code). And the _r variants are easy to implement in terms of the windows _s variants (or even in terms of the vanilla variants, given that they are threadsafe) on Windows. Looking at the OS X implementation the _r versions also look more efficient, though probably not enough to matter in the real world.
Seems fine, then to have a config macro indicating whether the _r variants exist, and use simple wrappers to the vanilla variants on platforms where they don't. -- Darin
participants (2)
-
Darin Adler
-
Maciej Stachowiak