Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!sdd.hp.com!apollo!mishkin From: mishkin@apollo.HP.COM (Nathaniel Mishkin) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Keywords: Asynchronous processing, threads, customization, fork() Message-ID: <4c555a34.20b6d@apollo.HP.COM> Date: 21 Aug 90 14:59:00 GMT References: <1990Aug13.231646.17415@athena.mit.edu> Sender: root@apollo.HP.COM Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin) Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA Lines: 83 In article <1990Aug13.231646.17415@athena.mit.edu> pae@athena.mit.edu (Philip Earnhardt) writes: >My main objection to the NCS philosophy is demonstrated in Mishkin's last >message <4bc8788d.20b6d@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". -- Nat Mishkin Cooperative Object Computing Operation Hewlett-Packard Company mishkin@apollo.hp.com