[patch] asynchronous callouts

Joe Shaw joe at ximian.com
Sat Apr 24 10:00:05 PDT 2004


On Sat, 2004-04-24 at 12:49 +0200, David Zeuthen wrote:
> 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?

Well, the problem is that they're all basically timing out at the same
time.  Here's how the calls used to work:

bus_device_visit (A)
   bus_device_got_parent
      add_to_gdl
bus_device_visit (B)
   bus_device_got_parent
      add_to_gdl
...
MAIN LOOP
callout (A)
callout (A)
callout (B)
callout (B)

etc.

Now, because so much of it has to be deferred until the main loop, we
get:

bus_device_visit (A)
bus_device_visit (B)
bus_device_visit (C)
MAIN LOOP
bus_device_got_parent (A)
MAIN LOOP
bus_device_got_parent (B)
MAIN LOOP
bus_device_got_parent (C)
MAIN LOOP
callout (A)
   add_to_gdl
MAIN LOOP
callout (B)
   add_to_gdl
MAIN LOOP
callout (C)
   add_to_gdl
MAIN LOOP

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.

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.

> 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.

Joe


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



More information about the Hal mailing list