Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!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
Keywords: NCS Threads Preemption
Message-ID: <1990Sep11.120119@apollo.HP.COM>
Date: 11 Sep 90 16:01:00 GMT
References: <1990Sep10.182341.11165@athena.mit.edu>
Sender: root@apollo.HP.COM
Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Organization: Hewlett-Packard Company - Cooperative Object Computing Operation
Lines: 26

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