Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.os.mach
Subject: Re: Wish explanation of some cthread calls
Message-ID: <34644@cornell.UUCP>
Date: 28 Nov 89 13:29:25 GMT
References: <113980001@hpcvlx.cv.hp.com> <113980003@hpcvlx.cv.hp.com> <34632@cornell.UUCP> <4ZQVTxC00hYP4whmM2@cs.cmu.edu>
Sender: nobody@cornell.UUCP
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 23

In article <4ZQVTxC00hYP4whmM2@cs.cmu.edu> Richard.Draves@CS.CMU.EDU writes:
>This is a pretty general problem.... Eric opted for simplicity...

Well, I don't know that I find this completely convincing.

Just to point it out, you could have some sort of index
associated with the per-thread data, e.g. making the rule
that index values > 0 are for the application and < 0 for
libraries; ISIS could then reserve a block of these, CAMELOT
could, etc.  The deal could even be dynamic as with INET
ports: specify index=0 and we pick an unused value and return
it for future use. 

So, I think this _could_ be solved, even if Eric favored
a less complex solution.

As for notify ports -- well, I see that as less of an issue
because a library can always create an extra task to hang around
waiting for notify messages and handle them -- on some port of
its own.

Ken
Ken