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.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id A5A2DBC6B for ; Tue, 28 Aug 2007 13:42:53 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7SBgrrR009057 for ; Tue, 28 Aug 2007 13:42:53 +0200 Received: from dslb-084-059-126-222.pools.arcor-ip.net [84.59.126.222] (helo=gate.lan.gerd-stolpmann.de) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1IPzTA2eZI-0006Zu; Tue, 28 Aug 2007 13:42:52 +0200 Received: from flakew.lan.gerd-stolpmann.de (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 3847BC054; Tue, 28 Aug 2007 13:42:52 +0200 (CEST) Subject: Re: [Caml-list] Has the thread cancellation problem evolved ? From: Gerd Stolpmann 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> <1188257636.7533.23.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-15 Date: Tue, 28 Aug 2007 13:42:51 +0200 Message-Id: <1188301371.7533.48.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V01U2FsdGVkX19VpKdsyDkJc9a2ObZkXu6sQkug909u1NZUzT9 pqGBCdW3tWr1CwNyH4wjjPDh6tKYLWPL21yLqKBgz4jkz/VNxc QA8kHq0vxZjED31HmVCmyL4zFYQVDzQ X-Miltered: at discorde with ID 46D40A3D.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 bunzli:01 gerd:01 stolpmann:01 toplevel:01 toplevel:01 computations:01 overloading:01 programmatic:01 recursion:01 runtime:01 computations:01 descriptors:01 viktoriastr:01 Am Dienstag, den 28.08.2007, 11:26 +0200 schrieb Daniel B=FCnzli: > Le 28 ao=FBt 07 =E0 01:33, Gerd Stolpmann a =E9crit : >=20 > > Nevertheless, I don't think this is a good thing. Raising an exceptio= n > > at potentially any moment is a problematic thing. E.g. code like > > > > let x =3D try Some(List.assoc ... with _) -> None > > > > where the author implicitly assumes that it is only Not_found that ca= n > > happen and the code is just plain wrong if anything else is encoded =20 > > into > > the exception. >=20 > But this is sloppy programming anyway. The author is plain wrong in =20 > assuming that only Not_found can be raised, he is asking for a =20 > potential time consuming debugging session. >=20 > 1) If x is polymorphic then List.assoc may raise Invalid_argument =20 > (because of compare). >=20 > 2) If the computation of x is embedded in a larger computation the =20 > call to List.assoc may raise Stack_overflow. >=20 > 3) The allocation of the block for Some may raise Out_of_memory. >=20 > 4) If we are in the toplevel Sys.Break may be raised. >=20 > IMHO the only place where a catch all handler is allowed is in a =20 > toplevel main loop (or a function monitoring other computations). Of course, my example is a bit simplistic. My point is that it is anyway difficult to get exception handling right in larger programs, and that overloading this mechanism with another feature is questionable. We have generally two kinds of exceptions: programmatic use to pass unusual result values back, or to exit some recursion (like Not_found), and those for runtime conditions/limitations (like Out_of_memory) (and some exceptions are in between). Handling the second type is difficult, as the program is probably already in a weird state when you try to handle the condition. Stopping threads is simple as long as if you only think of computations: yes, you can stop any computation by raising an exception. But I don't see a good way to stop I/O operations. Simply close all file descriptors? Yes, possible, but you may leave files in an unrecoverable state. It can even have very unwanted effects. Imagine you release locks at this moment - this may trigger other processes doing something. I see your problem, but there is no general solution. A thread of execution is always part of a larger system, and you cannot stop a system by stopping a thread. The word "stop" has simply no meaning in this larger context. Gerd --=20 ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany=20 gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------