On Mon, Jun 1, 2009 at 15:46, Alan Jenkins <alan-jenkins@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
