RPC Technologies
Philip Earnhardt
writes:
>>So, to paraphrase, the authentication and privacy features of NCS 2.0
>>are hardcoded. They could be changed by you folks if Kerberos doesn't
>>make it as a standard, but application developers (i.e. customers who
>>buy NCS) are stuck with it. I would not try to claim that there is
>>something inherently wrong with Kerberos, but if some developer has
>>a legitimate problem with it (perhaps because it uses the DES), and
>>they are working under NCS 2.0, they are stuck ... true? I suppose if
>>an NCS user really had to change it for their own reasons, they could
>>buy the NCS source and replace the Kerberos module...
>
>At worst. If the demand appeared to exist, I suppose we could document
>the interface between the authentication module and the rest of NCS.
>This would allow people to write authentication modules without having
>the source to NCS.
I'd rather not beat a dead horse, but ... this would then allow customization
by application developers ... clearly a limited form of customization (as
the 'RPC protocol' would presumably be left intact). Which leaves open the
question of what other sections of NCS may need to be 'customized' by the
end user. I do not believe that you would claim that you have thought of
all possible applications of NCS and therefore you could not have included
all things that the users may find neccesary. For this reason, Netwise-style
customizations, while not allowing all possible customizations, certainly
allows the users a great deal more flexibility in building their applications.
>>But again, you folks are constraining the choices of your customers.
>
>As does the C compiler writer who chooses to make his compiler save
>registers on ALL procedure calls, not just on those generated by a
>compiler targeted for a particular hardware architecture.
This is a very odd defense. To defend constraining your customers by pointing
the finger at other folks who have done so in the past is ludicrous.
>In NCS, we achieve
>the analogous optimization by telling people to declare a procedure to
>be "idempotent". Idempotence is a property of a procedure, not a network
>transport protocol. Since we're dealing in remote PROCEDURE calls, this
>seems like the more appropriate abstraction.
And if one of your customers chooses to use NCS/TCP, what will declaring
a procedure as idempotent do for them? Specifically what optimizations will
be applied?
>>With the Netwise approach, you get (in effect) _both_ CL and CO RPC
>>and allow user of the tool to decide for themselves which of these two
>>options is 'best' for their application. If a user wishes the advantages
>>of a CL RPC (largely reduced overhead) and is willing to pay the price
>>that implies (lost messages, etc.), they should have the opportunity
>>to make that decision. Clearly there exist applications that will benefit
>>from this.
>
>We've been over this again and again. People don't want "CL and CO RPC".
>They want RPC. They want to make certain performance tradeoffs made
>available to them. NCS addresses this desire in an appropriate way.
I am not sure how you can make such a sweeping generalization. Is this the
result of some HP marketing survey or do you believe that just by saying it,
you can make it true?
Nat, in going over the most recent postings from both sides, the signal to
noise ratio appears to be decreasing dramatically (Chuck McManis' encouragement
notwithstanding) ... shall we try to keep it to a more technical level? (This
posting was done with that intent)
------------------------------------------------------------------------------
The verbiage above does not neccesarily reflect the views of my employer or
client (Netwise).
jake edge - L & E Technologies, Inc. 2888 Bluff St. Suite 142 Boulder, CO 80302
Ma Bell: (303) 440-1142 UUCP: ...!onecom!wldrdg!jake
Nathaniel Mishkin
|> In <4bc8788...@apollo.HP.COM> mis...@apollo.HP.COM (Nathaniel Mishkin)
|> writes:
|> >At worst. If the demand appeared to exist, I suppose we could document
|> >the interface between the authentication module and the rest of NCS.
|> >This would allow people to write authentication modules without having
|> >the source to NCS.
|>
|> I'd rather not beat a dead horse, but ...
Me neither.
|> this would then allow customization by application developers ...
|> clearly a limited form of customization (as the 'RPC protocol' would
|> presumably be left intact).
I think the word "limited" is key.
|> Which leaves open the question of what other sections of NCS may need
|> to be 'customized' by the end user. I do not believe that you would
|> claim that you have thought of all possible applications of NCS and
|> therefore you could not have included all things that the users may
|> find neccesary. For this reason, Netwise-style customizations, while
|> not allowing all possible customizations, certainly allows the users
|> a great deal more flexibility in building their applications.
I won't deny that customization gives programmers more options. We
obviously have philosophically different opinions about whether increasing
the programmer's options in this way is ultimately a good thing, i.e.,
whether it yields a system that makes it easier to write and maintain
correct distributed applications or whether it would be better to learn
(admittedly, over time) what the programmer's real needs are an address
them in a coherent way in future versions of the product.
|> >>But again, you folks are constraining the choices of your customers.
|> >
|> >As does the C compiler writer who chooses to make his compiler save
|> >registers on ALL procedure calls, not just on those generated by a
|> >compiler targeted for a particular hardware architecture.
|>
|> This is a very odd defense. To defend constraining your customers
|> by pointing the finger at other folks who have done so in the past
|> is ludicrous.
I guess I don't see why it's an odd defense. I'm not pointing my finger
at any one else. I thought I was making a humorous analogy. I guess
I mixed up my complaints about Netwise's lack of (what we call) "transport
transparency" (i.e., ensuring constant call semantics regardless of what
transport you happen to be running RPC over) with my complaints about
customization. The analogy was that building a system that sometimes
yields one call semantics and sometimes another (depending on what
transport the application was running over) was like having a C compiler
sometimes preserve registers (that contains useful values) across calls
and sometimes not (depending on what hardware architecture the C compiler
was targetted for), yielding different program behavior.
I'll try to re-draw the analogy to apply to customization. If someone
said to a C compiler writer: "Hey look, I know what I'm doing and I
don't want you to save registers when I make this call; give me a way
of telling the compiler to not save registers", I think people would
argue that that kind of customization is a bad idea.
|> And if one of your customers chooses to use NCS/TCP, what will declaring
|> a procedure as idempotent do for them? Specifically what optimizations
|> will be applied?
I'm aware of none that can be applied. Is this a problem? The programmer
states an invariant fact about his procedure. Seems appropriate. The
underlying system may or may not be able to take advantage of this fact.
|> >We've been over this again and again. People don't want "CL and CO RPC".
|> >They want RPC. They want to make certain performance tradeoffs made
|> >available to them. NCS addresses this desire in an appropriate way.
|>
|> I am not sure how you can make such a sweeping generalization. Is
|> this the result of some HP marketing survey or do you believe that
|> just by saying it, you can make it true?
The day marketing can get me correct answers to questions like this will
be a happy one for me, believe me. Unfortunately, my experience has been
that it's hard or impossible to answer these questions by survey. Sometimes
one just applies one's own engineering sense and more limited interactions
with application builders.
All I know is that it has always been my impression (reinforced, BTW,
by things that marketing people tell me) that there's a large body of
programmers to whom "network programming" is a daunting prospect. I
have always taken the RPC model as a way to help those programmers by
hiding the network from them -- to relieve them from having to understand
things that you and I understand only too well. I am trying to develop
a system where, as the system evolves, programmers have to know less
and less about the network. In service of this goal, I try to make it
the case that the system doesn't require me to talk about "CL vs. CO"
in describing the system to its users.
-- Nat Mishkin
Cooperative Object Computing Operation
Hewlett-Packard Company
mis...@apollo.hp.com
-- Nat Mishkin
Cooperative Object Computing Operation
Hewlett-Packard Company
mis...@apollo.hp.com
Chuck McManis
>I guess I don't see why it's an odd defense. I'm not pointing my finger
>at any one else. I thought I was making a humorous analogy. I guess
>I mixed up my complaints about Netwise's lack of (what we call) "transport
>transparency" (i.e., ensuring constant call semantics regardless of what
>transport you happen to be running RPC over) with my complaints about
>customization. The analogy was that building a system that sometimes
>yields one call semantics and sometimes another (depending on what
>transport the application was running over) was like having a C compiler
>sometimes preserve registers (that contains useful values) across calls
>and sometimes not (depending on what hardware architecture the C compiler
>was targetted for), yielding different program behavior.
Fortunately for most programmers they specify "connection-oriented" and
get the exact same behaviour as NCS's connection oriented dressing over
most other transports. You are absolutely correct that if the programmer
say's "I'll take _any_ transport." The one they get will always work
but may not maintain strict procedure call semantics. And yet, if they
as for connection oriented transports, they will always get reliable
at most once semantics, unlimited argument size, and all those other
nice things that one may want at the expense of keeping some state
of the connection around. I've heard the argument that it is "more
efficient" for NCS to maintain that state than it is for the kernel
to maintain that state but state is state. Even the ECMA people
recognize this is a better way to implement these semantics and
specify TP4 as the underlying transport for ECMA 127.
>I'll try to re-draw the analogy to apply to customization. If someone
>said to a C compiler writer: "Hey look, I know what I'm doing and I
>don't want you to save registers when I make this call; give me a way
>of telling the compiler to not save registers", I think people would
>argue that that kind of customization is a bad idea.
And your entire argument goes up in smoke. You see, someone _did_ say
that to C compiler writers, and they _did_ say *I must have this* because
some people _do_ know better and they _don't_ want to have your choices
forced down their programmatic throat. In the C compiler arena these
are called "#pragma" statements and at least one C compiler I know of
lets you completely redefine the way in which calls are made by the
compiler! And guess what that's in the standard too!
Your belief that your customers don't want to be able to customize
their network applications is unfounded. There are people in both
camps. There always will be, NetWISE and Sun have always tried to cater
to both because they are all customers.
>All I know is that it has always been my impression (reinforced, BTW,
>by things that marketing people tell me) that there's a large body of
>programmers to whom "network programming" is a daunting prospect.
This is a tautology. You could just as easily say that there are a large
body of _people_ to whom "programming" is a daunting prospect. But
that doesn't justify making BASIC the only programming language.
>I have always taken the RPC model as a way to help those programmers by
>hiding the network from them -- to relieve them from having to understand
>things that you and I understand only too well. I am trying to develop
>a system where, as the system evolves, programmers have to know less
>and less about the network. In service of this goal, I try to make it
>the case that the system doesn't require me to talk about "CL vs. CO"
>in describing the system to its users.
I like it, a shade on the "I know better than you" side but it shows
a strong conviction. Would you feel better if we put using "connectionless"
transports in the advanced section of the manual? I think everyone can
agree on the goal, but most programmers disagree with the philosophy
that "we will decide what is best for you." That reeks of proprietaryness.
Think of it like a car manual. The first few pages start off with how
to start the car, shift gears and turn on the headlights. By the time
you get to the end of the NetWISE manual you can swap out carburetors
and reset the timing for maximum performance. Halfway through your
manual it says "no serviceable parts inside, go see your dealer." Sorry
but that doesn't cut it.
--
--Chuck McManis Sun Microsystems
uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcm...@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"I tell you this parrot is bleeding deceased!"
Philip Earnhardt
>>On page 43, the "Suggested Time" for fragment acknowledgment is 1
>>second (it's my understanding that all of these timers are hardwired
>>in a given NCS implementation). Isn't a 1-second timeout far too
>>short for fragment acknowledgment? If the mean round-trip time for 2
>>Internet hosts is 5 seconds, won't this mean that fragments will get
>>needless multiple retransmissions?
> Ugh. Suffice it to say that the spec should be taken with a grain of
> salt when it comes to parameters such as the one you're pointing to.
> We focused most of our energy on specifying the non-parametric aspects
> of the protocol. A correct implementation (e.g., NCS 2.0) would do round
> trip time estimations.
The Network Computer Architecture Book (describing NCS 1.x implementations)
gives "suggested times" for timer implementations. For your current products,
how do retransmission timers work? Specifically, do NCS 1.x implementations
on top of UDP/IP have a fixed retransmission timer or do they employ some sort
of adaptive algorighm?
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.
Philip Earnhardt
multi-threaded systems that have been somewhat lost in the recent discussion:
1. Asynchronous processing is a separate issue from RPC. Non-distributed
applications have and will continue to use asynchronous processing.
2. One very powerful way to use RPC technology is to take an existing
non-distributed application and use an RPC Toolkit to make it a distributed
application.
If you want to take an existing standalone application that uses asynchronous
processing and make your asynchronous call be a remote procedure call, we feel
the most straightforward thing to do is an Asynchronous RPC call. Our
asynchronous customization provides the three things you need to do that: a
routine to invoke the remote procedure, a routine to check the status of the
procedure, and a routine to get the results of the remote procedure. There
will be existing analogues to these routines in your non-distributed
application.
Alternatively, if you want to create a multi-threaded application for doing
the remote procedure call, fine. The Netwise RPC Tool will work correctly in
multi-threaded environments. My personal opinion is that multi-threading is
the wrong tool for the job (for a variety of reasons--see below). However, it
shouldn't matter what I think--the decision should be left to the designer:
3. Asynchronous processing and multiple threads are both tools that are
available to the developer of distributed application. Whenever possible,
both of these methods should be available to the designer of the
distributed application. Give the designer the choice.
My main objection to the NCS philosophy is demonstrated in Mishkin's last
message <4bc8788...@apollo.HP.COM> :
> Asynchrony is hard to understand. All the more reason to have a single
> abstraction -- the process/thread -- to deal with it.
Mishkin thinks Asynchrony is hard to understand; it is not available in NCS.
Why not give the designer the choice?
The July 9, 1990 issue of UNIX Today! contains the OSF DCE Rationale and
Netwise's response to it. Hopefully, these discussions about Asynchronous RPC
will give some insight into the customization issue discussed there.
----------------------------------------------------------------
In <4bc8788...@apollo.HP.COM> mis...@apollo.HP.COM (Nathaniel Mishkin) writes:
>> If you're doing asynchronous calls, you have some point when you have
>> enough information to perform the call, but don't need the result
>> immediately. A simple strategy is to go back to what you're doing until you
>> need the results, then block waiting for them.
> How do I get the results? In a synchronous call, the results are in
> the output parameters defined in the procedure signature. Do you create
> some other random stub procedure that just has output params or what?
> What if want to have more than one call executing concurrently? How
> do I coordinate and collect the results? With the multi-thread /
> synchronous call approach, the answer is create more threads and just
^^^^^^^^^^
> get the result via output parameters.
The exact way that our asynchrouous customization works is that the
application performs the asynchronous call twice. The first call sends the
calling parameters and any globals needed for the call. The second call blocks
until the call is complete, updates globals and return parameters and sets the
return value. A second routine lets them check the status of the call. As
noted above, this is pretty darn similar to what someone is doing for
asynchronous I/O in a standalone application.
If someone prefers "the answer" for his distributed application, he could
change the customization to use our select-like mechanism to check the status
of the concurrent calls. He would have changed the interface specification
to update the globals directly instead of having return parameters. They could
even have put each call in a separate thread, provided threads are available
in all environments.
I'm not too enthuiastic about "the answer" you've described, because it's
drifting away from Procedure Call semantics--the return vales for each of the
calls must also be stored in globals, too. An alternative would be to change
the customization to use the select-like mechanism to see when results are
available for each the concurrent calls, then get the results. Whatever.
>>> My religion says that they're a bad idea because they're hard to
>>> understand, represent an unnecessary new aspect in the computing model,
>>> and that one should use existing primitives for asynchrony (process) and
>>> communications (procedure call) together to achieve the same effect.
>> Do you mean that a process should fork a new thread to do the RPC call?
>> In your example, isn't the parent thread going to do stuff for "a while"
>> then "check for a result" of its child? Sounds at least as hard to me.
> Not necessarily. I might be collecting statistics about some remote system.
> Each thread makes a call to a different system and when the result appear,
> the thread inserts the info (using mutex locks, of course) into a common
> data structure. No one is "checking for results".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I don't understand. Someone is waiting for all of those results to come in. It
really doesn't matter if it's looking for return values or looking at a global
data structure.
What you are proposing is still an asynchronous call!
>> For other readers: it's useful to remember one other thing about async
>> operations. Async is pretty simple to understand if there is only one
>> outstanding operation. It is possible to have multiple async calls over a
>> connection, but the rules get much more complicated. I would not recommend
>> multiple outstanding asynchronous calls over the same connection.
> Exactly. See my comments above. Are you telling me async RPC is OK
> unless I want to do more than one remote thing at a time? Seems sort
> of a limiting model.
What I'm saying is that having multiple outstanding asynchronous calls on one
id involves extra management. This is a function of having multiple
asynchronous calls over one channel--it really has nothing to do with RPC. If
you're doing a non-distributed application with asynchronous calls, it also
involves more management to support multiple outstanding asynchronous calls.
I'd imagine it's pretty complicated (or maybe impossible) in NCS to
manage multiple outstanding asynchronous calls in a single thread. You
would probably create multiple threads. In the Netwise RPC sytsem, if you
wanted multiple async calls to the same server, you would have multiple
connection ids.
This would be extra overhead on the Netwise system. You have your choice of
separate ids for each of the asynchronous calls or non-trivial customization
to manage the calls over a separate id. Or you could examine your application
and see if it's really necessary to have multiple outstanding asynchronous
calls to the same server. The choice would rest with the designer of the
distributed system.
>> Yeah, it looks like multi-threaded systems will become more widespread. It
>> will be interesting to see what sort of problems that this unleashes on the
>> world. I'm not tremendously enthusiastic about locking out all other threads
>> every time I want to modify a global. The one that really frightens me,
>> though, is the process of software maintenance. Some junior programmer will
>> not understand THE RULES for changing a multi-threaded application and will
>> introduce bugs that will not surface for months later....
> Asynchrony is hard to understand. All the more reason to have a single
> abstraction -- the process/thread -- to deal with it. With a little
> language support (especially for stack-based exception handling and mutex
> locks) it's pretty tractable. I recommend Andrew Birrell's DEC SRC tech
> report on experience programming in such an environment (SRC Report 35,
> "An Introduction to Programming with Threads").
Assuming that this package does solve the problem, what is its availability?
Is it shipping on DEC platforms? Is the technique proprietary, or is DEC
willing to give it away to everyone? Will all vendors agree to use it, or will
they invent different schemes? In short, are you willing to guarantee
interoperability for this scheme on all multi-threaded platforms? If so, when?
As noted above, what you are doing is still an asynchronous call. It's
just hidden under the threads. If Asychrony is hard to understand,
Asychrony Obfuscated by Threads should be even harder to understand.
In <4b872c9...@apollo.HP.COM> mis...@apollo.HP.COM (Nathaniel Mishkin) writes:
> Why do you want to invent and make me use duplicate primitves
> (in support of async RPC)?
We support Asynchronous RPC via customization. Would NCS need to add
primitives to support Asynchronous RPC?
In <4bc8788...@apollo.HP.COM> mis...@apollo.HP.COM (Nathaniel Mishkin) writes:
>> Either multi-threading is a keystone of NCS, or it isn't. If
>> multithreading isn't available in all environments, then your proposed
>> mechanism of doing asynchronrous RPC via forking a thread won't work.
> Yes. You won't be able to make concurrent calls in environments that
> don't support threading. I also can't port my Unix programs that call
> "fork" to MS/DOS.
This hasn't really addressed the issue. Either multi-threading is a keystone
of NCS, or it isn't. If multi-threading is not available in all NCS
environments, then your proposed mechanism of doing asynchronous calls is not
portable. The presence or absence of "fork" in MS/DOS has no bearing on the
workability of Asynchronous RPC in that environment.
Matt Burdick
> in NCS. Why not give the designer the choice?
This seems pretty lame: some people think that threads are easier or
cleaner to use - yet Netwise doesn't offer that ability. Does this
mean that NetWise should "give the designer the choice" by offering
threads?
-matt
--
Matt Burdick | Hewlett-Packard
bur...@hpspd.spd.hp.com | Intelligent Networks Operation
Philip Earnhardt
Please reread my earlier posting--you have a couple of factual errors.
Netwise does support multiple threads. Also, any multi-threaded approach must
still use asynchronous semantics. You would have to be using both threads and
asynchronous semantics. How could this be cleaner and easier?
Matt Burdick
> Netwise does support multiple threads.
I thought one of the bad things about NCS was the difficulty of
porting it to platforms that didn't easily support multiple
lightweight task or thread emulation. Your previous posting doesn't
make it clear whether it is RPC Tool that provides multiple thread
capability or whether it will merely continue to function in an
environment (such as Mach) that already provides it.
> Also, any multi-threaded approach must still use asynchronous
> semantics. You would have to be using both threads and asynchronous
> semantics. How could this be cleaner and easier?
The threads *are* the asynchronous semantics. Picture two threads:
one is reading from a device and inserting new data in a global
database, the other is providing the user interface to the database.
Except for watching for mutual exclusion, neither thread needs to know
about the other's existance. A third thread could easily be added
that tweaks the database in a different way. The code for the first
two threads would not need to be modified in any way.
Nathaniel Mishkin
(Philip Earnhardt) writes:
|> The Network Computer Architecture Book (describing NCS 1.x implementations)
|> gives "suggested times" for timer implementations. For your current
products,
|> how do retransmission timers work? Specifically, do NCS 1.x implementations
|> on top of UDP/IP have a fixed retransmission timer or do they employ
some sort
|> of adaptive algorighm?
The former. As I said, this is a deficiency that's being corrected.
Nathaniel Mishkin
|> I've heard the argument that it is "more efficient" for NCS to maintain
|> that state than it is for the kernel to maintain that state but state
|> is state. Even the ECMA people recognize this is a better way to
|> implement these semantics and specify TP4 as the underlying transport
|> for ECMA 127.
The day I start basing performance decision decisions on statements of
international standards organizations... Well, you get the idea.
This whole "conversation" has gone on so long I can't remember whether
I made this point or not yet: The issue has nothing to do with NCS's
implementation or the fact that it's "based on datagrams" or whatever.
The right way to think about what we did was simply that we designed
a virtual circuit protocol with the knowledge in hand that RPC was going
to be layered on top of it. Doing so lets you better "piggyback"
information. For example, the initial "data" for the "connection" can
be passed in the connection "open" message.
|> And your entire argument goes up in smoke. You see, someone _did_ say
|> that to C compiler writers, and they _did_ say *I must have this* because
|> some people _do_ know better and they _don't_ want to have your choices
|> forced down their programmatic throat. In the C compiler arena these
|> are called "#pragma" statements and at least one C compiler I know of
|> lets you completely redefine the way in which calls are made by the
|> compiler! And guess what that's in the standard too!
"#pragma" may be in the standard, but the particular things you can SAY
in a pragma are not in the standard. Good luck if you use a pragma
to express some semantically relevant intent and you try to take your
code to another system/compiler that doesn't know about that particular
pragma option.
|> >I have always taken the RPC model as a way to help those programmers by
|> >hiding the network from them -- to relieve them from having to understand
|> >things that you and I understand only too well. ...
|>
|> I like it, a shade on the "I know better than you" side but it shows
|> a strong conviction. Would you feel better if we put using "connectionless"
|> transports in the advanced section of the manual? I think everyone can
|> agree on the goal, but most programmers disagree with the philosophy
|> that "we will decide what is best for you." That reeks of proprietaryness.
Well, what can I say? I clearly am not going to disagree with the point
that it's bad to have a "we know best" attitude all the time. It's a
matter of degree. When I call read(2), I don't get to control how long
the data stays in the buffer cache and I don't get to control how many
blocks are read ahead. Does this reek of proprietary-ness or is it
just "doing the right thing"?
Nathaniel Mishkin
>My main objection to the NCS philosophy is demonstrated in Mishkin's last
>message <4bc8788...@apollo.HP.COM> :
>
>> Asynchrony is hard to understand. All the more reason to have a single
>> abstraction -- the process/thread -- to deal with it.
>
>Mishkin thinks Asynchrony is hard to understand; it is not available in NCS.
>Why not give the designer the choice?
You are misrepresenting what I think to be my fairly clearly stated
position. Asynchrony *is* available when using NCS -- you get it by
using threads. When I said "asynchrony", I meant it in the large --
asynch coordination whether it's based on threads or based on some sort
of async RPC mechanism. Either way, it's hard to understand.
>The exact way that our asynchrouous customization works is that the
>application performs the asynchronous call twice. The first call sends the
>calling parameters and any globals needed for the call. The second call blocks
>until the call is complete, updates globals and return parameters and sets the
>return value. A second routine lets them check the status of the call. As
>noted above, this is pretty darn similar to what someone is doing for
>asynchronous I/O in a standalone application.
Does the first call return some "magic cookie" that I can pass to the
second call to corelate the two calls? If not, then can I not make two
async calls at the same time (i.e., in a row) without waiting for the
result in between? Can I call a call like Unix "select(2)" or "semop(2)"
in a way that lets me block waiting on a file descriptor or semaphore
AND the async call's completion? More customization required? With
threads these questions simply don't arise. If you need to do two calls
at the same time, you make two threads. If you need to do an N-way wait,
you create N threads and then synchronize (if necessary) using threading
primitives.
>I don't understand. Someone is waiting for all of those results to come in. It
>really doesn't matter if it's looking for return values or looking at a global
>data structure.
Like I said, I'm collecting statistics and maintaining a database. No
one is "looking" for anything. I'm making a remote call and storing the
result in the database. Simple.
>What you are proposing is still an asynchronous call!
What I'm still supporting is asynchrony. Asynchrony isn't an option.
It's a reality. The only question is how best to support it.
>Assuming that this package does solve the problem, what is its availability?
>Is it shipping on DEC platforms? Is the technique proprietary, or is DEC
>willing to give it away to everyone? Will all vendors agree to use it, or will
>they invent different schemes? In short, are you willing to guarantee
>interoperability for this scheme on all multi-threaded platforms? If so, when?
DEC has an implementation of the POSIX draft multi-threading interface
(Pthreads). This implementation will be part of the DCE product available
from OSF. The implementation has already been ported to several Unix
systems. An completely implementation of the PThreads interface is running
on top of Mach kernel threads. Presumably, when POSIX finalizes the Pthread
spec, it will become even more widely implemented.
>This hasn't really addressed the issue. Either multi-threading is a keystone
>of NCS, or it isn't. If multi-threading is not available in all NCS
>environments, then your proposed mechanism of doing asynchronous calls is not
>portable. The presence or absence of "fork" in MS/DOS has no bearing on the
>workability of Asynchronous RPC in that environment.
I don't know what you mean by "keystone". I tried to address the issue
by analogy, but I guess I failed. Any application that uses
multi-threading (as some NCS-based applications will, as that is the
only way to achieve asynchrony) will be portable only to systems that
support multi-threading.
My analogy was only trying to point out that I could also say "Any
application that uses ``fork'' to achieve asynchrony (as some Unix-based
applications will, as that is the only way to achieve asynchrony) will
be portable only to systems that support ``fork''". Hence, applications
that use "fork" will not be portable to MS/DOS. I haven't seen tons
of mail excoriating people for using "fork".