Re: Problems with the Stream interface



Miguel de Icaza <miguel@helixcode.com> writes:

> > > Remember that here anything that happens on one side of the pipe will
> > > happen on both sides:  even with an asynchronous interface, a client
> > > may be busy and the server will block if it tries to send the client
> > > some CORBA request.  It's exactly the same thing as on the other side.
> > 
> > You're right, but oneway addresses both concerns I think.
> 
> It really does not.  As I mentioned in a previous post the problem is
> that you can fill the system queue that you are using between
> components (or the tcp/ip queue) and your application will block.
> Oneway or no one way, this will happen.

I would hope that making a oneway call only schedules a message to be
delivered, and ORBit uses a hook in the glib loop to detect when the
relevant file descriptor is writable, to avoid blocking on writes
(although I have not verified this). If it doesn't, it shouldn't be
infeasible to add that feature, although I think the problem you
describe is far more theoretical than the one I am trying to solve.

> This might not be noticeable for methods like ref/unref, but you will
> definetly notice it on a trasnfer_big_chunk_of_data() kind of
> methods.  So oneway here is also approaching uselessness very
> rapidly. 
> 

Are you sure? We've never seen this phenomenon with the CORBA back-end
for gnome-vfs, which follows the same design I am proposing for the
Stream interface, and is pretty much a filesystem interface.

In any case, I think that what I propose is much better than what we
have now in most cases; I am pretty certain it would allow Nautilus to
avoid blocking the whole UI when viewing text or image files remotely
(and it _definitely_ does right now).

I am now unclear on what you want. Would you like me to continue to
pursue this approach (the next step will be to propose some specific
IDL), implement some different solution to this problem that you have
in mind, or not do this work at all?

 - Maciej





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]