On Thu, Sep 15, 2011 at 11:16 AM, Michael Schreckenbauer <grim...@gmx.de> wrote: > On Thursday, 15. September 2011 11:03:09 Michael Mol wrote: >> > Yes, except that udev ONLY handles kernel-events and doesn't process any >> > "actions" itself. >> > These are placed on a seperate queue for a seperate process. >> >> The problem with this is that you now need to manage synchronization >> between the kernel event processor and the action processor, which is >> actually more complicated than keeping them together in a >> single-threaded, single-process scenario. > > Yes, it's more complicated to do. But not impossible. > IPC, shared memory and what not, exists for a reason
Sure. But it's not KISS, it's not necessary and it's a royal PITA. One of queued tasks here at work is debugging _exactly_ that kind of code. You need a _very_ good reason to use it, because it doesn't make any solution more elegant. I don't see a pragmatic value to splitting the process. At work, I have to do it because it links to badly-written crash-prone code I can't fix. If I can reasonably guarantee that the code I need to run will behave, then the overhead and complexity definitely doesn't seem worthwhile. And because I've sat on two sides of the KISS argument in as many messages, I'd like to make some points clear: * The udev tool needs to be reliable, and this means no complexity unnecessary to fulfilling its role. However... * Part of udev's role needs to be *not* impose constraints on a system without a clear path to get from point A to point B; as long an API is understood, someone plugging into udev should be able to find a way to reliably do what they want to do. -- :wq
