Please do not reply to this email. You can add comments at http://bugzilla.ubuntu.com/show_bug.cgi?id=14495 Ubuntu | hal
------- Additional Comments From [EMAIL PROTECTED] 2006-01-03 09:49 UTC ------- (In reply to comment #105) > (In reply to comment #104) > > I'm not sure whether this is something that's been "accidentally" fixed -- > > we're > > still running the asynchronous remove script, maybe it's having less effect > > because we're not forking the old hal helper? Martin, any ideas? Has this > > been > > deliberately fixed, or is it just winning the race a bit more often now? > > I did not deliberately fix it because I did not have an idea how to do so, > apart > from the hal-umount.dev workaround (asking hal if it still knows the device). > > Not forking the helper could have solved it, though. Before the script was > executed completely asynchronously, which was subject to the race conditions > Andreas observed. Now udev directly executes the RUN script; if that happens > sequentially, then it's plausible that the race does not happen any more. If > udev still just forks off all scripts without waiting for termination before > running the next, then it just seems to be luck. The script is synchronous, udev will wait for it to complete before processing any further rules for the device... however I thought the problem was that: udev sends "add" event to hal, hal processes it in the background udev runs "remove" program, which beats the hal event Using the direct socket communication for the add event has probably simply given hal a head-start, rather than removed the race. -- Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. -- desktop-bugs mailing list [email protected] http://lists.ubuntu.com/mailman/listinfo/desktop-bugs
