From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA28290; Fri, 30 Nov 2001 22:16:32 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA28236 for caml-list@pauillac.inria.fr; Fri, 30 Nov 2001 22:16:31 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA25270 for ; Fri, 30 Nov 2001 18:53:00 +0100 (MET) Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id fAUHqxn17371 for ; Fri, 30 Nov 2001 18:52:59 +0100 (MET) Received: (qmail 28902 invoked by uid 50); 30 Nov 2001 17:52:58 -0000 Received: (qmail 28867 invoked by uid 0); 30 Nov 2001 17:52:57 -0000 Received: from adslppp170.tcsn.uswest.net (HELO dylan) (216.161.144.170) by tcsnpop1.tcsn.uswest.net with SMTP; 30 Nov 2001 17:52:57 -0000 Message-ID: <009401c179c7$f5065410$210148bf@dylan> From: "David McClain" To: Subject: [Caml-list] Re: SysThreads Date: Fri, 30 Nov 2001 10:53:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Well I ran into another problem here with a threaded DLL backend for a COM/OLE server. Since the incoming DLL requests are happening on arbitrary threads that have never been seen by the OCaml code (OCaml did not start them), these foreign threads are beyond the machinery of the OCaml threading engine. There are no control blocks established for them. Secondly, with a well controlled environment and only one thread making requests = the starter thread, I find that the use of the Reppy protocol in Event becomes unreliable when many small slave threads are spawned. Perhaps the system thread mechanism is too heavy handed for this approach. Reppy got by in CML with discarding the stack, using the heap for a spaghetti stack, and making lightweight objects under his sole control for threading. He also has GC incorporate thread scavenging. My fear is that M$ system threads are just too clunky for Reppy-style threading in Event.ml. I already realize that we can't fully implement Reppy's speculative threading, since the GC can't scavenge useless threads -- i.e., not yet dead, but will never be awekened for running. So anyway, I welcome any thoughts by the group... - D.McClain, Sr. Scientist, Raytheon Systems Co., Tucson, AZ ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr