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=1.0 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 0338EBC6B for ; Fri, 27 Jul 2007 11:14:17 +0200 (CEST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6R9EGTr009490 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jul 2007 11:14:16 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IELtm-0001W0-5C for caml-list@inria.fr; Fri, 27 Jul 2007 11:14:14 +0200 Received: from ivr94-8-88-162-26-239.fbx.proxad.net ([88.162.26.239]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Jul 2007 11:14:14 +0200 Received: from li by ivr94-8-88-162-26-239.fbx.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Jul 2007 11:14:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Zheng Li Subject: Why thread.cmi of vmthreads/systhreads different Date: Fri, 27 Jul 2007 11:15:35 +0200 Message-ID: <87bqdyw6ko.fsf@pps.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ivr94-8-88-162-26-239.fbx.proxad.net User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) Cancel-Lock: sha1:2tpK41owmh3fSsMSvMJI9YX4C2w= Sender: news X-Miltered: at discorde with ID 46A9B768.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; cmi:01 systhreads:01 cmi:01 stdlib:01 stdlib:01 mli:01 val:01 val:01 unify:01 systhreads:01 ocaml:01 threads:01 pps:01 pps:01 functions:01 Hi I found that the thread.cmi in $STDLIB/vmthreads and $STDLIB/threads are different, while others interface files (event.cmi, condition.cmi and mutex.cmi) are the same. By looking at the source, I found that the slight differences coming from two thread.mli on the following aspects: 1) a few values explicitly declared as "external" in the interfaces hence different from each other, as the implementations vary. e.g +val self : unit -> t -external self : unit -> t = "caml_thread_self" +external id : t -> int = "thread_id" -external id : t -> int = "caml_thread_id" However, by substituting "external" with "val" can obviously unify them. Is there any special reasons, except slight efficiency difference, to keep them external in the interface? 2) values "sleep", "wakeup" "critical_section" only exist in vmthread and "sigmask" only exist in systhreads. However, - Isn't it possible to complete these slots with dummy functions on both sides so that they can agree? Especially, "sleep" etc. are for internal use only and hidden from the doc by default, besides there already exist some precedents like that (e.g. wait_read and wait_right of systhreads) - The Thread module section of OCaml manual seems to be generated from the systhreads interface, then how about if I call Thread.sigmask on vmthreads? My point is that two different versions of thread.cmi greatly reduce the flexibility. I don't see many obstacles to make them agree, but I'm not sure whether there exist other factors to prevent that from happening. On the other hand, if this would never happen (officially), I'm fine with wrapping a common interface module, just a bit strange. -- Zheng Li http://www.pps.jussieu.fr/~li