https://github.com/basho/webmachine/pull/158 basho/riak_cs#954
Conclusion: you can't use httpd_util:rfc112_date/0
or httpd_util:rfc1123_date/1
for multicore performance because both acquires a lock on reading OS locale file with acquiring a lock tzset_lock
inside libc.
Survey was done at Debian jessie, glibc-2.19 with OTP R15B01.
But the benchmark says ok to httpd_util:rfc1123_date/0
and no to httpd_utild:rfc1123_date/1
. why?
rfc1123_date/0
-> calendar:universaltime/0 -> erlang:universaltime/0 -> get_universaltime (erl_time_sup.c) -> gmtime(3)
-> calendar:day_of_the_week/1 -> no distinct bifs
rfc1123_date/1
-> calendar:local_time_to_universaltime_dst/1
-> erlang:localtime_to_universaltime/1 -> bif.c -> local_to_univ (erl_time_sup.c) -> erl_mktime -> ... -> mktime(3)
-> erlang:universaltime_to_localtime/1 -> bif.c -> univ_to_lodal (erl_time_sup.c) -> localtime (3)
-> calenar:day_of_the_week/1
it locks a mutex to open a locale file
mktime(3)
-> __tzset(); -> tzset_lock -> tzset_internal(...) -> __tzfile_read(...) -> ... > fopen(...)
-> __mktime_internal(...);
time/tzset.c
void
__tzset (void)
{
__libc_lock_lock (tzset_lock);
tzset_internal (1, 1);
if (!__use_tzfile)
{
/* Set `tzname'. */
__tzname[0] = (char *) tz_rules[0].name;
__tzname[1] = (char *) tz_rules[1].name;
}
__libc_lock_unlock (tzset_lock);
}
gmtime(3) -> __tz_convert(...) -> tzset_lock
-> __tzset_internal(...) -> ...
-> __tzfile_compute(...) -> [[[
localtime(3) -> __tz_convert(...)
Bug ticket for glibc: https://sourceware.org/bugzilla/show_bug.cgi?id=16145