Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!samsung!caen!etsu!cmi.com!kevinh From: kevinh@cmi.com (Kevin Hegg) Newsgroups: comp.os.mach Subject: Re: Threads, Definition of Message-ID: <8703@etsu.CMI.COM> Date: 20 Feb 91 22:24:03 GMT Sender: news@etsu.CMI.COM Organization: EDS Corp - Center for Machine Intelligence Lines: 18 References:<1476@pdxgate.UUCP> <21892@oolong.la.locus.com> <1991Feb20.011728.15702@cs.ubc.ca> > This advantage is true, however most I/O calls that I want to do > within a thread will block anyway. File system calls are an obvious > example. Under NeXT mach, I can't do a read() without the whole > task blocking. > > Seeing as mach currently relies on much Unix code for I/O, the file > system for example, this blocking problem probably won't go away > until the fs code is redesigned specifically for Mach and threads. > I'm guessing at this point... At the Jan '91 Usenix conference a paper on the SunOS Multi-threaded Architecture was presented. Using a combination of threads and light-weight processes Sun provides a mechanism so that your entire task (process) doesn't block if a single thread blocks. Kevin Hegg, EDS Corp - Center for Machine Intelligence 2001 Commonwealth Blvd., Ann Arbor, Michigan 48105 Phone: (313) 995-0900 Internet: kevinh@cmi.com Applelink: D5990