From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id E79BDBDE6 for ; Sat, 3 Sep 2005 13:14:13 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j83BEDK7027292 for ; Sat, 3 Sep 2005 13:14:13 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA22049 for ; Sat, 3 Sep 2005 13:14:12 +0200 (MET DST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j83BEChS027285 for ; Sat, 3 Sep 2005 13:14:12 +0200 Received: by wproxy.gmail.com with SMTP id 67so642839wri for ; Sat, 03 Sep 2005 04:14:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H/7aaz0oSaB3y1jQ2Nq/qDkbtwBOxXGcuOxKQ86USgS/y0iop0xHpr/RL0uMwYoclNE6Ufi0aHc+9pC6CK5R01X6AvBQkSBOvzqI+T5qAYa+ParAIps08q5A/w79EdwzzyIfFyRpP7iacBixZ8MeFYYCQROkqyPkz2qSP83NmtU= Received: by 10.54.104.11 with SMTP id b11mr2050109wrc; Sat, 03 Sep 2005 04:14:11 -0700 (PDT) Received: by 10.54.154.7 with HTTP; Sat, 3 Sep 2005 04:14:11 -0700 (PDT) Message-ID: <891bd33905090304142aaa2679@mail.gmail.com> Date: Sat, 3 Sep 2005 07:14:11 -0400 From: Yaron Minsky Reply-To: yminsky@cs.cornell.edu To: Xavier Leroy Subject: Re: [Caml-list] Unix.localtime not threadsafe? Cc: Caml Mailing List In-Reply-To: <431956AC.1050008@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <891bd339050902103460db1a55@mail.gmail.com> <431956AC.1050008@inria.fr> X-Miltered: at concorde with ID 43198585.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 43198584.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; yaron:01 minsky:01 yminsky:01 caml-list:01 bug:01 bug:01 ocaml's:01 alloc:01 alloc:01 threads:01 ocaml:01 threads:01 ocaml:01 allocations:01 yaron:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.3 On 9/3/05, Xavier Leroy wrote: > > First off, the underlying localtime call is definitely not re-entrant. > > The tm data structure is shared among all calls, leading to the > > possibility of races. >=20 > As others mentioned, the C library implementation of this function > could use thread-local storage to avoid this particular race. I don't > think this is guaranteed, though. Indeed, the man page explicitly states that the function is not threadsafe. I think this counts as a bug, and I suspect I may have seen the bug in the wild. It seems like it would be simple and safe to use localtime_r instead. Should I submit a patch? > > If I understand the way ocaml's locking works, another thread could > > make a call to localtime where alloc_small is called. >=20 > No, at least not another Caml thread: GC triggered from C code > (e.g. alloc_small()) cannot cause context switches. So, from a Caml > standpoint, the call to localtime() and the following allocation of > its result are atomic. >=20 > > If there are mixed C threads and Ocaml threads, then a call by the C > > thread at that point could muck up the tm data structure before > > switching back to OCaml, thus leading to bad data getting into the > > tm data structure. >=20 > Yes, this is possible in principle if 1- some non-Caml threads call > localtime(), and 2- the implementation of that function does not use > thread-local storage. It's interesting to learn that context switches can't happen on c-land allocations. That simplifies a lot of things. But the C-interactions are still possible, so I would still argue for a fix. I'm still quite unsure if the bug I saw is a result of this race, and realizing that the race can't be between caml-threads makes me more unsure. Thanks for the help, Yaron