[patch] asynchronous callouts

[David Zeuthen]

On Tue, 2004-04-20 at 23:00, 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. 
> 
> So it's possible that whatever our callouts do might be discarded?
> 
> > This will give us several advantages
> > 
> >  - callouts can access the device using the UDI environment variable;
> >    no one else will know about the device until then (unless they
> >    are psychic :-)
> 
> They can't do this now?
> 

They can indeed do this now, but the real problem is that applications
are notified of the device before callouts get a chance to complete.
Which means a lot of nasty races.

For instance, g-v-m does a mount(1) and this is unsafe because the
/etc/fstab might not have been updated because we're not waiting for the
callouts. Another problem I've mentioned is that we possibly want to
merge properties and add capabilities.

> >  - properties merged and capabilities added from callouts doesn't
> >    generate d-bus events / callouts as the device isn't in the GDL
> 
> The properties stuff seems good, but wouldn't you want your capability
> callouts called as they're added?  Seems like a good separation of
> functionality there.  (And then you don't have to duplicate it between
> your device callout and your capability callout)
> 

A device might be 'born' with capabilities (though most of them are
merged when handling a class device) so anyone needs to check for both
device_add and capability_add. Hmm..

> > Oh, I read the code like hald_callout_device() returned before all
> > callouts were run?
> 
> Yes, but any subsequent calls to hald_callout_device() will just append
> those callouts to the queue.
> 

This is good, but we still need to wait for all callouts to terminate
before adding the device to the GDL. This means a lot of nasty
asynchronous code, I don't see any other way out of it...

Cheers
David



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