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: <1990Sep7.153710@apollo.HP.COM>
Date: 7 Sep 90 19:37:00 GMT
References: <1990Sep5.194621.11656@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: 29

In article <1990Sep5.194621.11656@athena.mit.edu>, pae@athena.mit.edu (Philip Earnhardt) writes:
>The alternative to this is to impose the semantic limitation that the user's
>appliction code must not run for "too long". This would qualify as a pretty
>arbitrary limitation to put on a distributed applications programmer.

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

I might say:

    Of course, Sun RPC has gotten by (or maybe not gotten by :-) for
    years with limitations of this sort (and more).  E.g., if you use
    Sun RPC over UDP/IP, you're limited to 8K worth of data and the call
    semantics are unpredicatble.  "Use Sun RPC over TCP/IP", you might
    say.  Oh well, then the number of concurrent calls I'm allowed to
    have is limited by the number of TCP connection I can (effectively)
    have open at a time.  Seems like a pretty arbitrary limitation to
    put on a distributed applications programmer.  The load of having,
    oh, 100 clients doing lightweight things may be low.  It's just the
    poorly chosen requirement the RPC package made on the system that's
    preventing me from doing what I want.

But I wouldn't want to compare NCS to Sun RPC :-)

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