Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!apollo.hp.com!mishkin
From: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Newsgroups: comp.protocols.misc
Subject: Re: RPC Technologies
Message-ID: <1990Aug27.094625@apollo.HP.COM>
Date: 27 Aug 90 13:46 GMT
References: <1990Aug27.015014.8881@athena.mit.edu>
Sender: root@apollo.HP.COM
Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Organization: Hewlett-Packard Company
Lines: 73

In article <1990Aug27.015014.8881@athena.mit.edu>, pae@athena.mit.edu
(Philip Earnhardt) writes:
|> 1. Does the implementation of NCS2.0 in an environment require that
thread
|>    support be available in the environment (or that a thread support
package
|>    be ported to that environment)?
|> 2. If an environment has native thread support, is that what's used?
Does the
|>    NCS system have the concept of providing a standardized threads
API in all
|>    environments?
|> 3. If the answer to #1 is no, what is the set of functionality that
will not
|>    be available to developers in non-threaded environments?  From
your above
|>    meeeage, it appears as if Asynchronous RPC will not be available
in a
|>    single-threaded environment. Will you be able to have server code
run in a
|>    single-threaded environment? Are there other NCS features that
|>    won't be available?

Gee, I really wasn't trying to hedge.  I guess I'll just have to be
very
clear this time.

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.)

NCS 2.0 does not contain its own threads package.  The NCS 2.0
implementation uses the PThreads API.  PThreads is a draft POSIX
standard
that seems to have high probability of being formally standardized.
However, NCS's use of PThreads is not so deep that this use couldn't
be replaced by use of another threads API and package.  We have no
plans
to do this work though.  (It would probably be easier simply to
implement
a subset PThread veneer over any "native" thread support.)

NCS does not support "async RPC" in the sense that Netwise (and others)
might use that term.  When using NCS, to achieve concurrency (what
we've
sometimes been calling "asynchrony"), you need a threads API and
package
available to the application programmer.  For any given implementation
("port") of NCS, an application programmer wanting to achieve
concurrency
will likely have to use the same threads package that that NCS
implementation uses, it being unlikely that two threads packages will
happily co-exists within the same address space.

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.

Like I've been saying, we believe in multi-threading and are actively
working to foster a standard threads API and the availability of
portable
threads implementations.  We think this view is shared by many people.

--
                    -- Nat Mishkin
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com