From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Mon, 26 Jan 2004 22:26:05 +0000 Subject: Re: [patch] udevd - cleanup and better timeout handling Message-Id: <20040126222605.GA7107@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: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... > Otherwise a simple connect from a client blocks the whole process. > > You may use select() for this and multiplex the connections, or fork > a child and maintain the queue in shared memory. But that's all not > really nice. I think threads are the nicest option, if you want sockets. Ok, I'll trust you here :) > > In udevd can't we just read the socket if any data is available? > > No, it blocks, until the client sends, or we need to poll. Even if you accept on a socket that has O_NONBLOCK set on it? > > No, I do not think klibc will ever support them, and state machines are > > much nicer than multi threaded apps (for the most part.) > > What kind of state machine you are thinking of? > How does it handle multiple client sockets. Do you mean a scheduler? Hm, I don't know what kind of state machine I'm thinking of, usually you can easily replace a program that has a lot of threads with a single one using a state machine. But I've also written stuff that can't be done that way (accepting serial data from one thread, etc.) > > If sockets don't really help much, I'll go add support to klibc for ipc... > > I'm fine with it. > We cant do it later if we want, when all the other problems are solved :) That sounds fine with me :) 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