From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA25303 for caml-redistribution@pauillac.inria.fr; Mon, 21 Feb 2000 17:57:06 +0100 (MET) Resent-Message-Id: <200002211657.RAA25303@pauillac.inria.fr> 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 KAA10755 for ; Fri, 18 Feb 2000 10:14:05 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA20597; Fri, 18 Feb 2000 10:14:04 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA31233; Fri, 18 Feb 2000 10:14:03 +0100 (MET) Message-ID: <20000218101403.40695@pauillac.inria.fr> Date: Fri, 18 Feb 2000 10:14:03 +0100 From: Xavier Leroy To: Christophe Raffalli Cc: caml-list@inria.fr Subject: Re: Thread feature missing References: <20000211111749.34427@pauillac.inria.fr> <20000213073403Q.garrigue@kurims.kyoto-u.ac.jp> <38A7B721.172F585C@univ-savoie.fr> <20000215170653.54672@pauillac.inria.fr> <38AA8A8B.17558090@univ-savoie.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <38AA8A8B.17558090@univ-savoie.fr>; from Christophe Raffalli on Wed, Feb 16, 2000 at 12:31:23PM +0100 Resent-From: weis@pauillac.inria.fr Resent-Date: Mon, 21 Feb 2000 17:57:06 +0100 Resent-To: caml-redistribution@pauillac.inria.fr > I think it is better to have one channel for each thread and wait > using Event.select that thread A or B send on their respective > channel. Am I right ? You can do that too. > I have another little pb which is that Many threads may be waiting > for A to terminate. So I could do a loop always sending on the > termination channel of A. But is there a better way ? A kind of > broadcast forever a value on a channel ? If you need that kind of stuff, you'd better not use the Event module and design your own "mailbox" mechanism using mutexes and conditions (as Gerd Stolpmann outlined). However, I would argue that a design where a thread needs to be joined by several other threads is broken. In most threads libraries (e.g. POSIX threads), you can join a thread at most once. > Yet another question: What is the size of a thread in both cases: > bytecode and native. > Is 1000 threads reasonable ? With bytecode threads, it's barely reasonable. Each thread consumes about 4 K of memory for its initial stack. With native threads, it's ways too much. E.g. LinuxThreads (or, really, the Linux kernel) supports 256 threads for normal users, 512 for the super-user. Again, I'd argue that a design that calls for thousands of threads is broken. See the periodic and lively discussions on comp.programming.threads on this topic. Instead of creating lots of short-lived threads, consider having a reasonable number of worker threads (e.g. 10), started once and for all, which pick things to do from a queue of requests. > What I mean is that a clean interface to pthread_cleanup_push would be > enough > And probably portable (I do not know for Win32 ?) No, Win32 has no equivalent of POSIX cancellation handlers. > A Last question: How to make the GC collects an inacessible thread ? > The pb is that the definition of inacessible is hard for a thread: > it means no pointer to the thread (thats easy), but also no more > common mutable variables or channel : the thread can not interact > with the outside world. Moreover, one must also define the outside > world by choosing a main thread ... I see no way to do this. > All this looks hard, but it is necessary for my application ! In a first > approximation I will have a lot of potentialy dead thread running > :-( Then consider alternative designs for the application. - Xavier Leroy