kuenishi/gist:c9867a6f219343344f51 Secret

## gistfile1.md

      
    Raw
  

              gistfile1.md
            
          
    Why we shouldn't use httpd_util:rfc1123_date/0,1

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?
entry point

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

why mktime should not be used

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);
}
Why gmtime(3) nor localtime(3) should not be used

gmtime(3) -> __tz_convert(...) -> tzset_lock
   -> __tzset_internal(...) -> ...
   -> __tzfile_compute(...) -> [[[

localtime(3) -> __tz_convert(...)