From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 88452BC6B for ; Mon, 27 Aug 2007 06:39:10 +0200 (CEST) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7R4d7lH028794 for ; Mon, 27 Aug 2007 06:39:09 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEju0UY7pw2h/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.19,310,1183300200"; d="scan'208";a="180223083" Received: from ppp59-167-13-161.lns2.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.13.161]) by ipmail01.adl2.internode.on.net with ESMTP; 27 Aug 2007 14:08:27 +0930 Subject: Re: [Caml-list] Has the thread cancellation problem evolved ? From: skaller To: Daniel =?ISO-8859-1?Q?B=FCnzli?= Cc: caml-list@yquem.inria.fr In-Reply-To: References: <9FA25C33-04DD-46BD-8959-873DDD2FFF82@epfl.ch> <1188055755.10796.37.camel@rosella.wigram> Content-Type: text/plain; charset=utf-8 Date: Mon, 27 Aug 2007 14:38:17 +1000 Message-Id: <1188189497.11749.66.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 46D2556B.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0200,:01 ocaml:01 runtime:01 model:01 model:01 computations:01 computations:01 synchronous:01 synchronous:01 ocaml:01 async:01 async:01 runtime:01 arises:01 denying:98 On Mon, 2007-08-27 at 01:47 +0200, Daniel Bünzli wrote: > Le 25 août 07 à 17:29, skaller a écrit : > > > There is something I don't understand here. > > What you don't understand is that ocaml has a runtime system which > leaves some room for designing around what exists at the os level. I do understand that, but it doesn't make any difference to the fact that if you're running OS threads you need to use OS facilities to support things like cancellation. Also I at least would not like to see some extra feature dependent on the current uniprocessor model, so hooking, say, the gc, or the global lock, may be a bad idea because in a future multiprocessor execution model those things may not be present. > > If the source of the problem is a blocking operation, the solution > > is simple: don't use blocking operations! > > This is not the source of the problem. What I want is to allow users > to initiate and cancel computations whenever they want. That is a reasonable crude idea, but not precise because you haven't specified what 'should' happen to any acquired resources which would normally be released under program control. > Computations > can be lengthy even tough they do not invoke a blocking operation. Agree. > The problem is that libraries are not -- and should not -- be > designed with cancellation in mind, say every function has an > optional parameter that allows to stop the computation. I cannot agree with that claim at this time. If a library acquires resources and should support cancellation, then the library must also make provision for relinquishing those resources, including on cancellation. It is a fact, that in C++ libraries have to be designed to handle unexpected *synchronous* exceptions.. they even have a term for it: 'exception safe', and it has a heavy influence on library design. So the actual evidence is that you're not correct: libraries DO have to be designed to allow for abnormal termination. Synchronous exception handling is part of Ocaml. Asynchronous exception handling is not. So whilst with synchronous exceptions you can expect the program to catch and deal with the exceptions because they're thrown by the users code in the first place, or at least a library documenting that this may happen, being able to handle async exceptions is likely to be an impediment to programming in a way that manages resources safely. I do know something about this -- I am responsible for an official National Body "veto" on the C++ Standard on this issue. (Exception safe coding support) Note that is just ordinary exception handling, particularly in a polymorphic context where you can't know what exceptions will be thrown.. we're still talking about synchronous exceptions. I have no doubt async exceptions will also influence library design. > Cancellation > should be a service of the runtime system, and denying its usefulness > because it could be misused makes no sense, I can also open a file > and never close it, it is a matter of programming discipline. I'm not denying usefulness, I believe I simply claimed it couldn't be implemented. The problem here is roughly that OS support automatic release of many resources held by a process, when the process is killed. But there is no corresponding support for threads. This issue arises EVEN for cancellation of Posix threads at defined cancellation points. C executes 'on exit' procedures. For C++ the issue has been a matter for years of study by subgroups of the ISO Standardisation committee. Also those responsible for system ABI's actually HAD to specify some kind of behaviour, including the answer to the question: what happens if an exception hits the bottom of a thread stack? Note that the issue is nontrivial. For example if you DO execute code after cancellation .. what happens on if there is a subsequent cancellation? What happens if the cancellation code blocks? I guess my point is: you're asking something difficult, even for OS design, and reflecting it in Ocaml is going to be even more problematic. To make progress here you might instead consider a hybrid solution. For example, Ocaml provide ability set a hook into the garbage collector. That may be a bad idea, I don't know. Perhaps with a hook you can complete a solution for certain kinds of application on certain OS, without imposing the responsibility for a complete solution on Inria. -- John Skaller Felix, successor to C++: http://felix.sf.net