Re: [GIT] Experimental threaded udev

[Alan Jenkins <alan-jenkins@tuffmail.co.uk>]

Kay Sievers wrote:
> On Tue, Jun 2, 2009 at 16:05, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>   
>> Version 5. I guess we should go for the signalfd stuff, it looks prett
>> nice. The socketpair instead of the rtsignal is also nice, it allows
>> us to pass back arbitrary data from finished events to the main
>> daemon.
>>     
>
> Version 7. We need to handle the netlink unicast addresses, they are
> not neccessarily the process pid, so we need to remember the netlink
> address.
>
> We also keep 2 workers around, and don't kill them, to handle incoming
> events without forking.
>
> Thanks,
> Kay
>   

Ok.

I think the patch breaks the settle control message.  It now sends the 
signal back to udevadm immediately, instead of postponing it until after 
handle_inotify(), which was apparently the point.

"
    Now udevadm settle will send a control message to udevd, which will
    respond by sending SIGUSR1 back to the waiting udevadm settle once it
    has completed the main loop iteration in which it received the control
    message.
   
    If there were no pending inotify events, this will simply wake up the
    udev daemon and allow settle to continue.  *If there are pending inotify
    events, they are handled first in the main loop* so when settle is
    continued they will have been turned into uevents and the kernel
    sequence number will have been incremented.
"

Perhaps it would be simplest to reorder the main loop so that 
handle_ctrl() comes after handle_inotify().  If I'm right, it could 
benefit from a comment pointing out that this order is significant and 
should be preserved.


That said, I don't completely understand the settle control message.  I 
don't get why udevadm-settle only sends it once at the start, instead of 
incorporating it as part of the delay loop.

Thanks
Alan