🚀 go-pugleaf

In article <1990Sep10.182341.11165@athena.mit.edu>, pae@athena.mit.edu (Philip Earnhardt) writes:
>In <1990Sep7.153710@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes:
>> I agree.  That's why I am (and OSF is) an advocate for a standard threading
>> interface with a portable implementation.
>> [...]
>
>Your response didn't address the question at hand. What are you going
>to do until PThreads (or some multi-threaded standard) is available in
>all environments?  Specifically, are ports of NCS permitted to use
>non-preemptive threads?

What are you looking for?  I said "I agree".  It's a limitation.  I'm
going to do nothing to make up for the lack of a preemptive threading
package.  As far as what is "permitted" -- I don't say what's permitted
and what's not.  (I suppose we could go off and discuss esoterica about
who will be able to use the "NCS" or "DCE RPC" trademarks and under what
terms, but that hardly seems worthwhile.)  A port of NCS that doesn't
have a preemptive threads package available to it will be less useful
(by some degree that's a function of what applications are doing) than
a port that does have such a package available.

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

In <1990Sep11.120119@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes:

pae> Again, let me paraphrase to see if I understand what you're saying here:
pae>
pae>	"A multi-threaded implementation of NCS must use preemptive threads."
pae>
pae> The alternative to this is to impose the semantic limitation that the
pae> user's application code must not run for "too long". This would qualify
pae> as a pretty arbitrary limitation to put on a distributed applications
pae> programmer.

mish> I agree.  That's why I am (and OSF is) an advocate for a standard
mish> threading interface with a portable implementation.  [...]

pae> Your response didn't address the question at hand. What are you going
pae> to do until PThreads (or some multi-threaded standard) is available in
pae> all environments?  Specifically, are ports of NCS permitted to use
pae> non-preemptive threads?

mish> What are you looking for?  I said "I agree".  It's a limitation.  I'm
mish> going to do nothing to make up for the lack of a preemptive threading
mish> package.  As far as what is "permitted" -- I don't say what's
mish> permitted and what's not.  (I suppose we could go off and discuss
mish> esoterica about who will be able to use the "NCS" or "DCE RPC"
mish> trademarks and under what terms, but that hardly seems worthwhile.)

Gee, I thought the original question was pretty clear: Are non-preemptive
thread implementations permitted? "I agree" isn't an appropriate answer to
such a question. 

Who does say what's permitted and what's not permitted in an NCS port?
What's to keep someone from making a port that doesn't interoperate with
another NCS port?

mish> A port of NCS that doesn't have a preemptive threads package available
mish> to it will be less useful (by some degree that's a function of what
mish> applications are doing) than a port that does have such a package
mish> available.

You could say something even stronger than this. Ask the question:

   How does someone create a distributed application using NCS such that
   his distributed code is portable to all environments?

or perhaps

   What portability problems does NCS itself create?

Based on what you've said above, someone who wants a portable NCS application
had better make sure that his code doesn't run for "too long".

Do you think it's important to support users in creating portable NCS
applications? 

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.

In article <1990Sep11.223905.13417@athena.mit.edu>, pae@athena.mit.edu (Philip Earnhardt) writes:
>Who does say what's permitted and what's not permitted in an NCS port?

A good question that many people have tried to address in the context
of many existing protocols (and programming languages, and ...).  I don't
know that I have a good answer.  The strictest answer is that what's
permitted and required are exactly what some spec says is permitted and
required.  The creation of such a spec that is absolutely complete is
a very tricky matter.  It took a long time and a lot of experience to
get, say, the TCP spec(s) (plus notes to implementors) into a state where
multiple implementors who read the specs actually produce implementations
that interoperate.  Even though most people simply clone existing TCP
implementations these days, one STILL sees the occasional interoperability
problem.  What's more, I'm not aware of any official "conformance test
suite" for TCP, although such a existence suite would seem to be an
extraordinarily useful adjunct to specs.

We believe that in the current NCS spec we have gone a long way toward
making a complete spec, but clearly it's not absolutely complete.
Questions such as you're raising -- "Is an implementation conformant
if it can deal only with calls of short duration" -- is not explicitly
addressed in the spec.  It should be.  I am reluctant to strictly disallow
such implementations, since allowing them does have some value.  Let's
say we'd put it in the "Minimal NCA/RPC" appendix to the spec.

By the way, I don't know that I've ever seen a spec of the Netwise RPC
protocol (i.e., the one that your current, non-SunRPC-based products
use).  Can you make one available?

>What's to keep someone from making a port that doesn't interoperate with
>another NCS port?

In general, the only thing that stops someone from making a
non-interoperating implementation (port or brand new) of some network
protocol is market pressure.  What's to keep someone from making an
implementation of TCP that doesn't interoperate with another TCP
implementation?  (Some protocol definers try to leverage the legal system.
As I recall, Sun doesn't let a vendor use the "NFS" trademark unless
the vendor's implementation passes some verification suite.  Not an
unreasonable idea.)

>Do you think it's important to support users in creating portable NCS
>applications? 

No, and I don't like apple pie either :-)

Of course it's important.  But you seem to treat everything as black
and white.  ALL systems have aspects that limit portability to some extent.
Like I said, if I use Sun RPC over TCP and I need to handle 100's of
clients, my application is not going to be portable to systems that support
only 20 file descriptors per process.  Does that mean the system is
useless?  No.  Does it mean it's less useful than one that requires only
1 file descriptor.  To some degree, yes.  How does this "degree" map
onto the space of real world systems and applications?  Time will tell.

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