Re: [patch] udevd - cleanup and better timeout handling

[Greg KH <greg@kroah.com>]

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