From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Mon, 26 Jan 2004 19:28:19 +0000 Subject: Re: [patch] udevd - cleanup and better timeout handling Message-Id: <20040126192819.GA3237@kroah.com> List-Id: References: <20040125200314.GA8376@vrfy.org> In-Reply-To: <20040125200314.GA8376@vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Mon, Jan 26, 2004 at 08:11:10PM +0100, Kay Sievers wrote: > On Mon, Jan 26, 2004 at 10:22:34AM -0800, Greg KH wrote: > > On Sun, Jan 25, 2004 at 09:03:14PM +0100, Kay Sievers wrote: > > > 1. We are much too slow. > > > We want to exec the real udev in the background, but a 'remove' > > > is much much faster than a 'add', so we have a problem. > > > Question: is it neccessary to order events for different devpath's? > > > If no, we may wait_pid() for the exec only if we have another udev > > > working on the same devpath. > > > > But how will we keep track of that? It's probably easier just to wait > > for each one to finish, right? > > We leave the message in the queue until we reach the SIGCHLD for this > pid. So we can search the queue if we are already working on this devpath, > and delay the new exec until the former exec comes back. Ok, if that isn't too much trouble. > Is it feasible to run in parallel for different paths, or can you think > of any problem? I can't think of any problem with that. > > > We may want threads for this, but klibc doesn't support it. > > > Nevermind, the ipc stuff is also not supported :) > > > Any idea? > > > > Heh, I can easily add the ipc stuff to klibc. > > I'm not a experienced enough userspace programmer to discuss the merits > > of either option here. Anyone else? > > IPC is from the 70's :) It's not refcounted so we may leave messages in the > kernel without any process using it. Sockets are nicer, we easily recognize, > if the daemon isn't running. But we need threads for this to implement it > without doing things like I/O multiplex or use of shared memory, cause > all tasks need to work on the same global queue. > > So if we can get threads in klibc, I would prefer to switch to sockets. > IPC isn't really a option for a todays program, but it works for us and > sockets don't solve any big problem we have. Where would we need threads to do this? In udevsend? Can't we just send the message to the socket and forget about it there? In udevd can't we just read the socket if any data is available? I really, really want to stay away from threads. No, I do not think klibc will ever support them, and state machines are much nicer than multi threaded apps (for the most part.) If sockets don't really help much, I'll go add support to klibc for ipc... thanks, greg k-h ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel