From owner-freebsd-hackers Mon Jun 3 07:05:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA16754 for hackers-outgoing; Mon, 3 Jun 1996 07:05:54 -0700 (PDT) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA16747 for ; Mon, 3 Jun 1996 07:05:49 -0700 (PDT) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id KAA18435; Mon, 3 Jun 1996 10:05:18 -0400 Date: Mon, 3 Jun 1996 10:05:17 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@freebsd.org Subject: re: supporting coda threads. In-Reply-To: <199606021949.OAA00608@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > (from john dyson) > One of the middle-layer VM enhancements that I plan to add for 2.2 is > true-shared address spaces. Will this help? well i think it depends on the level of threading, i.e. if you use fork()+shared address space instead of threads and the context switch overhead is too high maybe it won't work. That's why i'm wondering about how much threading is going on. I'm going to grab the code this week at some point and look around. FYI: in the ZOUNDS DSM i wrote there is a little thing called filemalloc() and filecalloc(). Works just like malloc/calloc, except it's in mmap'ed files so you can have shared data across fork. This is a poor man's way to implement "threads" for those systems without rfork(). ron