linux - After kill(getpid(), sig), is the signal guaranteed to be delivered before the next statement? -
assuming you're in single-threaded process, , relevant signal not blocked or ignored, guaranteed that:
kill(getpid(), sig);
will result in signal being delivered before next line of code executed?
in particular, if signal 1 there no handler , whole default action terminate process (e.g. sigterm, sigalrm), guaranteed next line of code won't executed?
i had assumed (at least on linux) answer "yes", because thought before returning syscall kernel check see if there pending signals , deliver them if so. think have observed (when run on heavily-loaded, multi-core system) not case, though hard reproduce , i'd appreciate confirmation i'm not seeing things.
[this question similar is signal sent kill parent thread guaranteed processed before next statement? except that question asking multi-threaded processes (for answer "no"), whereas question single-threaded processes.]
yes. if you're in single threaded process, posix gives guarantees this.
if value of pid causes sig generated sending process, , if sig not blocked calling thread , if no other thread has sig unblocked or waiting in sigwait() function sig, either sig or @ least 1 pending unblocked signal shall delivered sending thread before kill() returns.
Comments
Post a Comment