Todd Lipcon has posted comments on this change. Change subject: [util] added Subprocess::GetExitStatus() ......................................................................
Patch Set 5: (1 comment) http://gerrit.cloudera.org:8080/#/c/4648/5/src/kudu/util/subprocess.cc File src/kudu/util/subprocess.cc: PS5, Line 349: // Block all signals for a while: if a signal delivered to the forked : // child before execv(), the parent's signal handler will be executed. : // This is not the expected behavior here. Also, some signal handlers of the : // parent is not async-signal safe (e.g., glog-related handlers). : // In the child's code, the signal handlers are reset to defaults except for : // SIGPIPE, which is ignored. It's a duplicated work since execv() resets : // the handlers as well, but at least it helps to get rid of unexpected : > As I understand, this is not just a TSAN bug. What prevents a signal to be In the case that the original signal was sent to the parent, then the child wouldn't receive it, right? (the child has a different pid). It would only receive a signal if someone sent it to the _new_ pid, but the new pid hasn't been "exposed" yet, right? Or is the issue that we could have already returned from the parent call, while the child has still not "exec"ed, and then we send the signal? Would it be better to use vfork instead of fork to avoid this, perhaps? -- To view, visit http://gerrit.cloudera.org:8080/4648 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ic2b16e2a2a53a01982f816b9ee41cc61fd93d4bf Gerrit-PatchSet: 5 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: Dinesh Bhat <din...@cloudera.com> Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-HasComments: Yes
