From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] vfork and paging
From: rog@vitanuova.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-vutpzoswoxsspikcnszknbftyq"
Message-Id: <20011002141933.8AE16199F3@mail.cse.psu.edu>
Date: Tue,  2 Oct 2001 15:31:44 +0100
Topicbox-Message-UUID: fa37f1d2-eac9-11e9-9e20-41e7f4b1d025

This is a multi-part message in MIME format.
--upas-vutpzoswoxsspikcnszknbftyq
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

the down side of this is that when debugging or inspecting the code,
it's not immediately obvious whether a given function is running as a
proc or a thread; e.g.  where shared access to a data structure might
be a problem, or where a system call is intended to block all other
threads.

  rog.


--upas-vutpzoswoxsspikcnszknbftyq
Content-Type: message/rfc822
Content-Disposition: inline

The acme paper talks about this a little.  Our threads are really just
user-level coroutines.  Their utility is that schedulding is easy to
understand: thread switching will occur only at communication points.
This means that no interlocking of data structures is required between
threads in the same process, and it's easy to write applications (like
acme) that use processes to gather I/O and send the data to a single
central process composed of lots of threads.  The total amount of
locking, and potential for concurrency bugs, is greatly reduced.

-rob


--upas-vutpzoswoxsspikcnszknbftyq--