Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
From: Richard.Draves@CS.CMU.EDU
Newsgroups: comp.os.mach
Subject: Re: Wish explanation of some cthread calls
Message-ID: <4ZQVTxC00hYP4whmM2@cs.cmu.edu>
Date: 28 Nov 89 05:30:37 GMT
References: <113980001@hpcvlx.cv.hp.com> <113980003@hpcvlx.cv.hp.com>,
	<34632@cornell.UUCP>
Sender: rpd@M.GP.CS.CMU.EDU
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 13
In-Reply-To: <34632@cornell.UUCP>

Ken Birman makes a good point when he notes that libraries can't safely
use the cthread calls to associate data with a thread.  I can't speak
for Eric, but I think having a simple way to associate data with a
thread is better than nothing:  it keeps simple programs simple.  A
complicated library will have to fall back on using its own mechanisms
(ie, hash table) to associate data with a thread, which it would have
had to do anyway if cthreads didn't provide this mechanism.

This is a pretty general problem.  For example, a task has only one
notify port, and if different libraries try to receive notifications
from it they will interfere with each other.

Rich