From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Mon, 26 Jan 2004 22:56:20 +0000 Subject: Re: [patch] udevd - cleanup and better timeout handling Message-Id: <20040126225620.GA11364@vrfy.org> 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 02:26:05PM -0800, Greg KH wrote: > On Mon, Jan 26, 2004 at 08:42:44PM +0100, Kay Sievers wrote: > > On Mon, Jan 26, 2004 at 11:28:19AM -0800, Greg KH wrote: > > > 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: > > > > > > > > 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? > > > > udevd need to be able to talk to multiple senders at the same time. > > Hm, we can't use the same socket? I need to read up on how that all > works... You bind() one and then listen() on it. If one connect() to it, you accept() and use this file descriptor to communicate and bind and listen on a new one. So now you have the problem: You have multiple sockets open and must handle it all at once. You have the option of nonblocking I/O with stupid polling or better with select() which notifies you if a socket has data for you. Or the forking of childs, each child takes the accepted socket and the parent opens a new one. If we fork for every new connection, we lose the queue and need shared memory, other ipc, pipes or files... But the problem is getting more complex if you want to do other thing at the same time like exec a list of udevs in the background and handle timeouts... This is all possible with a single process, but I don't want to debug such a beast. All problems magically go away with threads, cause we share the same address space and let the kernel schedule our tasks. Kay ------------------------------------------------------- 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