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=HTML_MESSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id AF56CBBC1 for ; Mon, 21 Apr 2008 23:16:52 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAFAGahDEjAXQIn/2dsb2JhbACCMzakPYNc X-IronPort-AV: E=Sophos;i="4.25,691,1199660400"; d="scan'208";a="11223686" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 21 Apr 2008 23:16:52 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m3LLGqpQ017635 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 21 Apr 2008 23:16:52 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsBAGahDEhA6aq+dGdsb2JhbACCMzaOagEMAwQHBxSVHYNc X-IronPort-AV: E=Sophos;i="4.25,691,1199660400"; d="scan'208";a="11739248" Received: from rn-out-0910.google.com ([64.233.170.190]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Apr 2008 23:16:51 +0200 Received: by rn-out-0910.google.com with SMTP id i6so533046rng.2 for ; Mon, 21 Apr 2008 14:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=k+y0BGS0KcBda6Xvs0lNEEj8COez/NM58srwBirUGLY=; b=w+4HZFpDLmNLy+Pn9RAbYvbtuCkFKhnM1bxl2JSBFKnu4lU9DVK9bh6dLj+frK2/bmfLfIHqxjeUK0IIMJPelgTlLL3IRPzknkkscQwxSa5EMNHdVW6BPU7GnVxYRbLOGmF7a8b0govvsE+GLv5OvwzjWqxA1NUoJ2KggwOz2i4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=t1PyNflvyu31+QUY3sFQDOGgmBeEbuI7aY71Aph1eoMllDf7n52kQ/8fzsa17/xeSV4XSUMktNCYPFuQdlSHy3zbMs3W6Z4+S7kL5Bk14ezEEFtrUIoKGVpk0JbLlaTGotJGv1kGvCbYS1ko3m9UDL41aGTFz3sV9TL6hgJoxuw= Received: by 10.142.58.14 with SMTP id g14mr1888203wfa.313.1208812609232; Mon, 21 Apr 2008 14:16:49 -0700 (PDT) Received: by 10.142.153.9 with HTTP; Mon, 21 Apr 2008 14:16:49 -0700 (PDT) Message-ID: Date: Mon, 21 Apr 2008 23:16:49 +0200 From: "Berke Durak" To: "Arnaud Spiwack" Subject: Re: [Caml-list] The closing gap (warning: long, inflammatory rant) Cc: "Caml List" In-Reply-To: <480D01E4.5060207@lix.polytechnique.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15587_30043295.1208812609226" References: <20080421131151.GA16777@annexia.org> <200804211544.08897.jon@ffconsultancy.com> <20080421204721.GA11434@annexia.org> <480D01E4.5060207@lix.polytechnique.fr> X-Miltered: at concorde with ID 480D0444.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 jocaml:01 low-level:01 threading:01 model:01 mutable:01 malloc:01 malloc:01 abstraction:01 jocaml:01 low-level:01 threading:01 X-Attachments: cset="UTF-8" cset="UTF-8" ------=_Part_15587_30043295.1208812609226 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Richard Jones: > Garbage collectors and _not_ using threads both improve the safety of the language. Arnaud Spiwack: > This might depend on what kind of thread interface you are provided with. > Of course it's never easy to work with non-determinism, but if I take jocaml > for instance, which gives you a process (in the sense of pi-calculus) > interface to threads, and it makes it probably rather safe actually, > possibly stronger safety when dealing with multiple processes (or UI threads > possibly) than doing things with low-level primitves like fork and such. > That's the point. The conventional threading model (mutable shared data and mutexland) is unsafe by default. It's like the good old days of manual memory management in C, except that you replace malloc/free with pthread_mutex_lock/pthread_mutex_unlock and signal 11 by deadlocks. But it's actually worse because mutexing doesn't compose as well as malloc. This means that it's difficult to increase the abstraction level. -- Berke ------=_Part_15587_30043295.1208812609226 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Richard Jones:
> Garbage collectors and _not_ using threads both improve the safety of the language.

Arnaud Spiwack:
This might depend on what kind of thread interface you are provided with. Of course it's never easy to work with non-determinism, but if I take jocaml for instance, which gives you a process (in the sense of pi-calculus) interface to threads, and it makes it probably rather safe actually, possibly stronger safety when dealing with multiple processes (or UI threads possibly) than doing things with low-level primitves like fork and such.

That's the point.  The conventional threading model (mutable shared data and mutexland) is unsafe by default.  It's like the good old days of manual memory management in C, except
that you replace malloc/free with pthread_mutex_lock/pthread_mutex_unlock and
signal 11 by deadlocks.

But it's actually worse because mutexing doesn't compose as well as malloc.  This means that it's difficult to increase the abstraction level.
--
Berke

------=_Part_15587_30043295.1208812609226--