From freedesktop-dbus  Fri Dec 14 16:14:05 2007
From: Michael Meeks <michael.meeks () novell ! com>
Date: Fri, 14 Dec 2007 16:14:05 +0000
To: freedesktop-dbus
Subject: Re: [Accessibility] Re: [Accessibility-atspi] D-Bus AT-SPI - The
Message-Id: <1197648845.18678.108.camel () localhost ! localdomain>
X-MARC-Message: https://marc.info/?l=freedesktop-dbus&m=119764866828945

Hi Rob,

	Thanks for your great feedback, to expand on this:

On Tue, 2007-12-11 at 14:09 +0000, Rob Taylor wrote:
> >>> 	+ A simple example is the flow of accessible events,
> >>> 	  each event often causing the sink to emit multiple
> >>> 	  round-trip calls to the source to fetch more
> >>> 	  information.
> 
> Urk, flow control is hard. The problem with the solution you propose is
> it forces an application to have a thread for processing events, and
> then you still end up with a possible starvation situation when handing
> off events to a mainloop.

	Well, right - if you install another broker you need more flow control:
in this case to the main-loop. Of course, if you handle this on the
mainloop, then you don't have that problem ;-) and can just ignore the
events.
	
> As its stands I've yet to see a real-world usecase for pumping signals
> faster than user input, though of course, we've tested this case ;). In
> AT-SPI the event reception is dwarfed by synchronous calls to handle an
> event, usually to the process that sent the event, so starvation isn't
> an issue here.

	Well, it used to happen quite easily with key-events; just turn the
auto-repeat rate up, and hold down a key: now of course, it's easy
enough to make the AT do enough work on each event to bog the system
down, and get a produce/consumer rate problem.

	Of course - we 'solved' this problem in at-spi by going synchronous for
all events; but ... ;-) that's not such a wonderful solution either.

> IIRC, libdbus at the moment currently always reads data off the socket
> into a queue of messages to be handled, it'd probably be good to have a
> method for applications to set a maximum queue size so they can use a
> direct connection and have the kernel manage their flow control. This
> should really be a design decision for an application writer, I don't
> think we can solve it for them in a decent way - and its not common.

	Sure; it's a matter of just having a separate queue I guess, though of
course you have to be able to stop polling on the incoming socket
as/when the queue is full etc.

	HTH,

		Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot


_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus