[Top][All Lists]

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

Re: scrolling optimization + asynchronous updates impossible

From: Marcus Brinkmann
Subject: Re: scrolling optimization + asynchronous updates impossible
Date: Sun, 16 Jun 2002 17:36:15 +0200
User-agent: Mutt/1.3.28i

On Sat, Jun 15, 2002 at 03:56:18PM -0400, Roland McGrath wrote:
> > Actually, fs_notify.defs is using routines, not simpleroutines, and we have
> > special hacks in libdiskfs and console to get simpleroutines... delivering
> > them synchronously would work as well, although it would not be so good if
> > you have multiple clients.
> I think that might just have been an oversight, and it seems entirely
> reasonable for filesystems to refuse to do anything synchronous (let the
> message queuing do it).

If Thomas agrees, I will change it to simpleroutines, because I agree.
> > BTW, if the port queue is full, the call blocks in the server, even if it is
> > a simple routine, because the MiG stubs don't have a timeout (or notify
> > port).  I just tried it: Using ports_manage...one_thread, the server will
> > block during operation, and the effect is that we have almost synchronizity
> > where the server is always a couple RPCs ahead (as many as the queue can
> > hold).  In the case of several clients, this would block other clients, too.
> Ack.  It should use timeout=0 and let the user lose if he didn't drain his
> port queue fast enough.

I agree here, too.  Currently, it is quite convenient for me, though :)
The problem is that you really would like to know about it when this
happens.  OTOH, the user of such a console probably would notice and refresh
the display.


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]