From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p6698bE5025396 for ; Wed, 6 Jul 2011 11:08:37 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4BANElFE7Nm0HimWdsb2JhbABTmRYCjmsUAQEBAQEICwsHFCWtTZ9WhjYEh0aKe4UDi1k X-IronPort-AV: E=Sophos;i="4.65,485,1304287200"; d="scan'208";a="112634421" Received: from diamond.nps.edu ([205.155.65.226]) by mail1-smtp-roc.national.inria.fr with ESMTP; 06 Jul 2011 11:08:23 +0200 Received: from virginia.nps.edu ([205.155.65.15]) by diamond.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 02:08:21 -0700 Received: from Adric.ern.nps.edu ([172.20.216.170]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 02:08:00 -0700 Received: by Adric.ern.nps.edu (Postfix, from userid 760) id 094D317130; Wed, 6 Jul 2011 02:06:05 -0700 (PDT) From: oleg@okmij.org To: caml-list@inria.fr Message-Id: <20110706090605.094D317130@Adric.ern.nps.edu> Date: Wed, 6 Jul 2011 02:06:05 -0700 (PDT) X-OriginalArrivalTime: 06 Jul 2011 09:08:00.0104 (UTC) FILETIME=[341BF680:01CC3BBC] X-Validation-by: oleg@okmij.org Subject: [Caml-list] Re: Race conditions with asynchronous exceptions in standard library Just a few clarifications. The posted Queue code gives the segmentation fault when compiled with ocamlopt without threads. When bytecode-compiled, the code is accidentally safe, at least on my platform. The bytecode interpreter checks for signals when executing any of the `application' instructions or popping the exception handler. It just so happens that no function application instructions were executed in the critical section of the standard library Queue code. That is a mere accident however: a new version of the standard library (or Batteries) might add some sort of debugging printing; or the code generation will change to emit calls to auxiliary, debugging or tracing facilities. Incidentally, comments in the bytecode interpreter justify a particular piece of code by saying that a signal handler may raise an exception. Thus Xavier Leroy certainly did allow for such signal handlers, at least as a possibility. Mark Shinwell wrote: > Specifically in the case of signal handlers, I would recommend > restricting processing in them to an absolute minimum, and in > particular not throwing exceptions. If this is the consensus, to which INRIA assents, it ought to be written in the user documentation, alongside of other warnings (like living in harmony with GC). At the same time, one should describe the recommended solution to Yit's original problem, to interrupt a long-running library function with a timeout.