Capabilities workshop, followup questions

[Bart van Leeuwen]

On Sun, 18 Jun 2000, Robert Watson wrote:

> 
> On Mon, 19 Jun 2000, Bart van Leeuwen wrote:
> 
> > With regard to capabilities I think it is a good idea to look at the
> > purpose of threads vs processes. Imho the purpose of threads is to create
... snip ...
 
> in Coda and AFS servers (except for housekeeping) generally represent a
> single RPC in execution.  As a single server serves multiple clients in
> the process, different threads are, in effect, acting with different
> rights.  In Coda and AFS, the authorization issue doesn't come up as they
> provide their own authorization and authentication modules.  However, for
> distributed system services using the same authentication and
> authorization schemes, such an environment would require the server
> software to make use of multiple processes, or reduce parallelism.  If
> threads could individually handle things such as capabilities, uid status,
> etc, then it would be possible.

But wouldn't that make threads a kinda lightweight child processes?
Maybe it is a better idea to create an actual lightweight process that has
such things as capabilities etc instead of extending threads to a realm
thats really not where they belong (imho ;-)

Anyway, I wouldn't know if such a thing is needed, for that I do too
little development work, but I understand why a kinda lightweight child
process might be the way some people view threads, and I think that leads
to confusing and sometimes bad implementations as well as usage.

I think that it is not a good idea to blur the difference between a thread
and a process, it is hard enough for most people right now already ;-)

As for the add. spinlock I can see why, but I think (but heh, who am I) 
that that is the price to pay for a model that has less of a tendency
to lead to flawed usage and implementations because it is imho clearer and
easier to undertand ;-)



To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message