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 LAA13060; Sun, 11 Apr 2004 11:02:13 +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 LAA13038 for ; Sun, 11 Apr 2004 11:02:12 +0200 (MET DST) Received: from aomori.annexia.org (annexia.force9.co.uk [212.56.101.183]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3B938jq000947 for ; Sun, 11 Apr 2004 11:03:08 +0200 Received: from rich by aomori.annexia.org with local (Exim 3.36 #1 (Debian)) id 1BCaqm-0001Z6-00; Sun, 11 Apr 2004 10:02:00 +0100 Date: Sun, 11 Apr 2004 10:02:00 +0100 To: skaller Cc: caml-list@inria.fr Subject: Re: [Caml-list] exene and ocaml ? Message-ID: <20040411090200.GA5788@redhat.com> References: <16491.38344.186267.44292@soggy.deldotd.com> <1080807590.13854.260.camel@pelican> <6C27A642-83BE-11D8-96B0-000393863F70@exomi.com> <1080828521.13854.358.camel@pelican> <16504.59825.814348.947278@soggy.deldotd.com> <1081672912.20677.340.camel@pelican> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1081672912.20677.340.camel@pelican> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Richard Jones X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 threads:01 threads:01 sidestepping:01 slower:01 tlb:99 wiki:01 dbi:99 ltd:98 ocaml:01 sig:01 behaviour:01 cope:02 stacks:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 246 On Sun, Apr 11, 2004 at 06:41:53PM +1000, skaller wrote: > Also, small address space processors cannot cope > with the linear addressing problem: unlike processes, > threads share address space. If you have a lot of threads > you need a lot of stacks, and they all have to grow > 'arbitrarily' large,[...] I did some experiments with early versions of pthrlib (see .sig) where I tried swapping stacks in and out during context switches using mmap(2). All thread stacks were located at the same address in memory, thus sidestepping the address space problem. It sort of can be made to work: It was about 3 years ago, so I forget the exact problems, but they were probably related to the fact that you need to back each stack with a disk file, and it doesn't work well with the normal GROWSDOWN behaviour of stacks. Plus it's probably a lot slower because you're trashing the disk cache / data cache and TLB on each switch. If you do this you have to be careful not to share data on the stack between threads (not normally a problem). BTW, very interesting your comments on Control Inversion. I think you're absolutely spot-on with that, and you should write up a node on the Portland Wiki about it. I don't think the term "Control Inversion" is well-known, although it should be. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment PTHRLIB is a library for writing small, efficient and fast servers in C. HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/ ------------------- 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