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 UAA06147; Sat, 12 Oct 2002 20:54:18 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA06113 for ; Sat, 12 Oct 2002 20:54:17 +0200 (MET DST) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id g9CIsGD23112 for ; Sat, 12 Oct 2002 20:54:17 +0200 (MET DST) Received: (qmail 73700 invoked from network); 12 Oct 2002 18:54:15 -0000 Received: from adsl-host-sf-228.apexworld.net (HELO checkerlap.d6.com) (66.114.212.228) by relay1.pair.com with SMTP; 12 Oct 2002 18:54:15 -0000 X-pair-Authenticated: 66.114.212.228 Message-Id: <4.3.2.7.2.20021012114058.02ec19e0@mail.d6.com> X-Sender: checker@mail.d6.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 12 Oct 2002 11:54:07 -0700 To: John Max Skaller , caml-list@inria.fr From: Chris Hecker Subject: Re: [Caml-list] gc question: thread stacks, fibers, etc. In-Reply-To: <3DA84EE0.806@ozemail.com.au> References: <4.3.2.7.2.20021004000748.030bd2c0@mail.d6.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >>In C, you implement them by mallocing a stack and with a little snippet >>of asm, or mucking with the jmpbuf fields. They're pretty trivial to get >>working fairly robustly >.. and fairly useless in most demanding applications due to the >impossibility of dynamically extending/shrinking the stack. >If that isn't a problem .. you might as well just use >real threads .. Hmm, not sure I understand the last sentence there. If you care about not having a fixed stack, you can handle it in the same way a thread handles its stack if you're willing to write os-dependent code (set guard pages, catch exceptions, etc.). In ocaml, you can probably realloc in a non-os-dependent way fairly effectively, because you've got all the stack frames around in the frame tables and there are no pointers into the stack (well, except if you've called C functions in the middle...hmm). Ignoring that, one reason you want fibers instead of threads is that you don't want preemption for some problems because it complicates your code to handle the asynchrony. If you're saying you should just use non-preemtive threads (or make them non-preemptive with mutexes), well that's what I'm calling fibers. Chris ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners