On Mon, Apr 07, 2014 at 03:12:49PM +0200, Michael Haggerty wrote: > > How far *do* you want to go? I'm certainly not opposed to field-test your > > current changeset (plus and adjustment to use sig_atomic_t) -- overall it > > is an improvement. And then we will see how it works. > > For now I think I'd just like to get the biggest problems fixed without > making anything worse. Given that there might be a GSoC student working > in this neighborhood, he/she might be able to take up the baton. > > I changed the patch series to use a new "volatile sig_atomic_t active" > field rather than a bit in a "flags" field. That seems like a good place to stop for now. If any code touches the fields, it can unset the "active" flag (even temporarily), and restore it when the structure is in a known state. I'm not sure if we can ever reach full safety. If you have an event loop, the sane thing to do is set an atomic flag in your signal handler and then handle it on the next iteration of the loop. But all of our signal handlers are jumped to from arbitrary code, and are just going to die(). There's nothing to return to, so any useful work we do has to be done from the handler. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html