On Mon, 30 Sep 2013 14:44:22 -0400 (EDT) Benjamin Kaduk <[email protected]> wrote:
> handling signals. Unblocking a few signals around calls to spawnprocve() > is slightly racy, and we can do better -- 10126 is basically saying "the I was hoping that http://gerrit.openafs.org/#change,8749 would eventually be committed to the source tree so I could use it. > Unix semantics are silly, unblock all signals in the child process and let > it set its own mask if it wants", and 8749 is giving the caller control > over the signal mask of the child process. > > I think either one is workable, and it really boils down to a design > decision for the procmgmt library about what its interface should be. > (The original authors seem to have not considered this design decision.) > The code in is more flexible, and is closer to "create the > child in a pristene environment". You probably shouldn't change the default behaviour of pre-existing users of this routine. It is difficult to predict what side effect this might have since I don't know who is already using this library. Lastly, I imagine there might be cases where one would like the signals to propagate to children. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
