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 KAA14565; Fri, 30 Nov 2001 10:49:45 +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 KAA14560 for caml-list@pauillac.inria.fr; Fri, 30 Nov 2001 10:49:44 +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 KAA14008 for ; Fri, 30 Nov 2001 10:30:03 +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 fAU9U2n23075 for ; Fri, 30 Nov 2001 10:30:02 +0100 (MET) Received: (qmail 17630 invoked by uid 50); 30 Nov 2001 09:30:00 -0000 Delivered-To: fixup-caml-list@inria.fr@fixme Received: (qmail 17601 invoked by uid 0); 30 Nov 2001 09:30:00 -0000 Received: from adslppp170.tcsn.uswest.net (HELO dylan) (216.161.144.170) by tcsnpop1.tcsn.uswest.net with SMTP; 30 Nov 2001 09:30:00 -0000 Message-ID: <000701c17981$b1560030$210148bf@dylan> From: "David McClain" To: Subject: [Caml-list] SysThreads and Win/NT DLL's Date: Fri, 30 Nov 2001 02:30:47 -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 see now that it takes more than just one Lazy.force on the proposed lazy init clause. In fact, any of the Thread routines that can accept a non-Thread.t argument potentially needs the same Lazy.force inserted. ...but still, this isn't too bad... Alas, any program statements that call upon these Thread routines at the top level, e.g., non-closures with Thread calls for value, need to be delayed as well, so that the DLL can successfully start up without spawning new threads -- a no, no, in DllMain. Of course the other possibility is to avoid calling caml_startup() altogether from inside of DllMain, and instead handle deferred initialization in other DLL entry points. That avoids the problem entirely, but forces less automatic behavior on the user of the DLL. - 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