Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!snorkelwacker!bloom-beacon!pae
From: pae@athena.mit.edu (Philip Earnhardt)
Newsgroups: comp.protocols.misc
Subject: Re: RPC Technologies
Message-ID: <1990Aug29.012657.1305@athena.mit.edu>
Date: 29 Aug 90 01:26:57 GMT
Sender: Phil Earnhardt (onewom!wldrdg!pae)
Organization: Netwise, Inc.
Lines: 29

In article <1990Aug27.094625@apollo.HP.COM>, mishkin@apollo.HP.COM
(Nathaniel Mishkin) writes:

> The NCS 2.0 implementation is multi-threaded (hence it requires a
> threads package to be usable).  We found this the most natural and
> simple way to do the implementation.  I believe other
> implementations of the same network protocols could be constructed
> in a way that does not require a threads package.  (NCS 1.5, which
> is compatible with NCS 2.0, does not require a threads package.)

> If someone builds an NCS implementation that does NOT require a
> threads package, and the environment does not otherwise contain a
> threads package, application programmers will not be able to achieve
> concurrency.

Just to make sure I understand you clearly, let me re-state what
I think you've said:

    While current NCS2.0 implementations are multi-threaded via the
    POSIX PThreads package, there is no architectural restriction that
    all ports of NCS2.0 must either use PThreads for their
    implementation or even that all ports use multiple threads.

Finally, are the multiple threads of a NCS2.0 implementation cooperative -- do
current implementations need a preemptive multi-threading package?

Phil Earnhardt          Netwise, Inc.  2477 55th St.  Boulder, CO 80301
Phone:303-442-8280      UUCP: onecom!wldrdg!pae
My opinions do not reflect any official position of Netwise.