Re: Problems with the Stream interface

[Maciej Stachowiak <mjs eazel com>]

Federico Mena Quintero <federico@helixcode.com> writes:

> 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.
> 

I don't think this is a problem with oneway calls.

> 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.
> 

The goal here is to avoid blocking the server (weird, I know), not to
avoid blocking the client, although both are laudable of course.

BTW, I don't hate threads personally, but it's way too late in the
development cycle to convert nautilus from async to threads.

 - Maciej