[patch] asynchronous callouts

[David Zeuthen]

On Sat, 2004-04-24 at 19:00, Joe Shaw wrote:
> Now, the problem is that bus_device_got_parent() only gets called with
> parent != NULL iff the device is already in the GDL.  If device A is the
> parent of device C, you can see that there's no way that C will have the
> parent A, because A isn't added to the GDL until well after
> bus_device_got_parent() is called for C.  That's the crux of the problem
> here.
> 

Yes and the root problem has to do with the fact that we special case
things when probing, e.g. we have a timeout of zero seconds. 

I've now changed this - basically it works because we don't search for
parents when we can infer, by looking at the sysfs path, that the device
cannot have a parent.

So the changes I suppose that needs to be done are the following:

 1. Remove callouts from gdl_store_changed

 2. All the places we do a hal_device_store_add to the gdl needs
    to be replaced with the initiation of the callouts. When the
    callouts complete a callback should be called to add the device
    to the gdl.
    The call would look like much the same way as e.g. the function 
    hal_device_store_match_key_value_string_async.

 3. Same for when removing devices from gdl

I'm not sure we need callouts to run before sending out dbus signals
when adding/removing capabilities and when properties change.

> What I was thinking was that we could remove most of the logic from the
> got_parent functions for most types of devices, call the pre_process and
> got_udi methods out of the visit functions, but it seems like there's a
> fair amount of dependency on the parent in those functions.  Block
> devices need the parent for detect_media(), for example.  usbif devices
> need the parent for calculating the UDI, etc.
> 

This wouldn't work - I think the approach I've sketched above will work.

> > It would probably be good to see a patch or something, it's a bit
> > difficult to grasp all this :-)
> 
> Yeah... It's at the office unfortunately. :(
> 
> I hope this gives a little better idea what's going on.
> 

Yup.

Hope this helps,
David


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