[patch] asynchronous callouts

[David Zeuthen]

On Fri, 2004-04-23 at 21:20, Joe Shaw wrote:
> On Thu, 2004-04-22 at 23:53 +0200, David Zeuthen wrote:
> > On Thu, 2004-04-22 at 23:41, Joe Shaw wrote:
> > > On Tue, 2004-04-20 at 22:45 +0200, David Zeuthen wrote:
> > > > Ok - thinking a bit more about it, we should probably callout right
> > > > after merging from .fdi files..
> > > > 
> > > > That is, just before adding to the GDL but after the device is named. 
> > > > 
> > > > This means our D-BUS access functions also must search the TDL
> > > > (temporary device list), but this should be an easy fix.
> > > 
> > > Ok, I've started on this.
> > 
> > Very nice.
> 
> Ugh.  This is all becoming very messy because so much more stuff is
> becoming asynchronous.
> 

Well, yes - I'm wondering if there is any way to avoid this? I really
want to avoid multi threading the daemon since that means a whole other
bag of problems. 

An idea that I've toyed with early on was handling all the device
building in the hotplug callout - the d-bus interface, it's called
something like org.freedesktop.Hal.AgentManager, is still there though
I'm not sure how well they work. The nice thing about this is that you
can block in these instead of all this asynchronous handling.

Anyway, I still think it's more sane to have everything in a single
process. And we are oh so close :-)

> I'm going to simplify the example to just the bus devices, since that's
> what I ran into first.
> 
> The way it is now:
> 
>         1. bus_device_visit() is called for all of the bus devices
>         immediately.
>         
>         2. An async call to bus_device_got_parent() is set up, once the
>         parent is set.  But because we're probing initially and things
>         are examined in order, this is a synchronous call.
>         
>         3. bus_device_got_parent() generated a permanent UDI and adds
>         the device to the GDL.
>         
>         4. The callouts are queued up in hal_callout_device().
>         
>         5. The callouts are called in a loop as a part of the main loop;
>         properties are added well after the device is in the GDL.
>         
> I have to change this basically to call the callouts in
> bus_device_got_parent() instead of adding it to the GDL, and then
> listening for a signal for when the callouts for a device are done and
> then add the device to the GDL.
> 

Right - it's basically the same for class devices; remember the special
case for block devices when adding/removing the HalDevice representing
an optical disc.

> This means that we'll have to get rid of the "is_probing" special case,
> since the devices won't be immediately and synchronously added to the
> GDL in order.  They'll have to be added as their callouts are completed.
> 

This is correct - in fact it sounds sane to get rid of that special case
called is_probing; we only seem to use it for selecting timeout to be
zero or not. So, this means that if we don't find a parent we just
timeout later. No big deal.

It will also mean we can just visit the devices in any order which
should be a nice test of the robustness of the code.

> The problem I am seeing now is a firehose effect.  Basically all of the
> async calls to bus_device_got_parent() are now timing out at the same
> time, and the parent/child relationships aren't getting set up.
> 
> So I am a little stuck right now.  Did I do a decent job of explaining
> this?  Any suggestions?
> 

The policy for bus-devices is that we add them regardless of them having
a parent. So maybe this is because the child times out before the
parent? Even though we actually started the timeout at the parent before
starting it for the child?

Perhaps we shouldn't search for a parent for devices in the top of the
tree? E.g. if the sysfs path is of the form

  /sys/devices/pci0000:00/0000:00:07.1

then just add it to the GDL without a parent, whereas devices of the
form

  /sys/devices/pci0000:00/0000:00:07.1/ide0

will search for a parent.

It would probably be good to see a patch or something, it's a bit
difficult to grasp all this :-)

Hope this helps,
David


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal