Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!apple!snorkelwacker!bloom-beacon!pae
From: pae@athena.mit.edu (Philip Earnhardt)
Newsgroups: comp.protocols.misc
Subject: Re: RPC Technologies
Keywords: NCS Threads Preemption Portability
Message-ID: <1990Sep11.223905.13417@athena.mit.edu>
Date: 11 Sep 90 22:39:05 GMT
References: <1990Sep10.182341.11165@athena.mit.edu> <1990Sep11.120119@apollo.HP.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: Netwise, Inc.
Lines: 57

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.