Re: Problems with the Stream interface

[Federico Mena Quintero <federico helixcode com>]

Maciej Stachowiak <mjs@eazel.com> writes:

> I have a proposal for how to solve this problem. Essentially, we need
> to make the Stream interface asynchronous by design. We can start with
> the current Stream interface and convert all calls to not return a
> value and take some sort of response listener object to which they
> will deliver the results when ready. This is much like the gnome-vfs
> CORBA interface for asynchronous I/O.

This is fine, but it does not completely solve the blocking issue.
Think of a "busy" server that essentially acts like this:

	while (1) {
		sleep (way_too_long);

		process_incoming_corba_requests ();
	}

Even if you have asynchronous interfaces, the server may take a long
time to be able to take in the client's requests, and the client will
block inside ORBit when it makes a request.

After the request goes in, the client essentially doesn't care anymore
since it will receive the result asynchronously anyways.

Basically, there is no way to solve the blocking problem for good
without using threads.  This is where you realize that maybe there
*is* some fundamentally evil part to the universe.

  Federico