From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Mon, 01 Jun 2009 13:57:02 +0000 Subject: Re: [GIT] Experimental threaded udev Message-Id: List-Id: References: <4A1EA138.10400@tuffmail.co.uk> In-Reply-To: <4A1EA138.10400@tuffmail.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: linux-hotplug@vger.kernel.org On Mon, Jun 1, 2009 at 15:46, Alan Jenkins wrote: >> Right, it's a rlimit, and I think I checked and remember 40.000+ >> signals here. The workers could detect, and re-send a non-queued >> signal, if needed. > > Non-queued signal transmission isn't blocking either.  The signal just gets > dropped if there's already one in-flight. Oh, I meant we get an error back, if we can not queue the signal, so we can re-send it. The rt-signals should be fully reliable regarding that. > Ok.  I meant we could send all the completions down the same pipe, which > wouldn't require lots of FDs.  Before this patch, we were happily sharing > kernel_monitor->sock between all the child processes. Ah, I see. Yeah, we share the inotify fd still, I think. We could have a pie, sure, if it's better for some reason. Scott mentioned signalfd, which we could look at too. Rt-signals might be bit more efficient than a pipe, we should find that out. >> Maybe we can set the event to QUEUED, when a worker dies with an event >> attached. >> > > Retry the event, you mean?  How many times? :-). Not sure. :) > The code looked like you freed the worker, but left the event RUNNING, and > it would never be released.  I would delete the event instead, just like the > old system. > > I haven't read V2 yet though, maybe you fixed it. I just set it back to QUEUED for now. Not sure if droppin git or re-trying it a few times would be better. Thanks, Kay