Asynchronous, Bi-Directional ONC-RPC: status + input requested

[Derek Atkins]

David Merrill <dmerrill@lupercalia.net> writes:

> Tell me why asynchronous calls are needed? Indeed, tell me why
> callbacks are needed at all. What's so wrong with the client blocking
> on a server call? If the call takes long enough for the user to notice
> the blocking, it is a bug. K.I.S.S.

There is nothing inherently wrong with clients blocking for calls.
The "problem" occurs when you try to implement callbacks.  Perhaps I
wasn't clear in my ramblings?

You need callbacks for Event Notification and data "liveness" in
distributed client caches.  Basically, when data changes on the server
you need an asynchronous callback to the client in order to inform
them that data has changed.  This is important when you have multiple
clients reading (and caching) data and someone making modifications.
If clients never cache data, then sure, you probably don't need this.

However, if clients are going to cache data, then you need some way to
'invalidate' the cached data.  One way (e.g. the NFS way) is to have
the client check with the server every time you want to use the data.
Another way (e.g. the AFS way) is to have the server notify the client
when cached data changes.  The latter mechanism is more
network-friendly, however it requires callbacks.

So, assuming we agree that callbacks are necessary, the question is
what limitations, if any, do you put on them or on our implementation
using the callbacks.  Another question is what dependencies do you
want to put on the server that would be making callbacks.  If we don't
care that we depend on, say, pthreads, and if we don't care that we
invoke a new thread for every service call, then quite honestly there
isn't a big problem (this was option 1a :) However, then the server
needs to be more threads-aware.  The alternatives are to limit what
callbacks can do, or change the RPC model.

-derek

PS: The "problem" is in my current implementation: when a service
request is called, the dispatch function is called from within the
background reader thread.  If that service call makes a blocking
request (callback), then the background reader thread becomes
deadlocked.  The deadlock occurs because it is waiting for the reader
thread (namely itself) to wake it up (which it obviously cannot do).

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available