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.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
_______________________________________________
Gnome-accessibility-devel mailing list
Gnome-accessibility-devel@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
