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

Popular posts from this blog

c# - SVN Error : "svnadmin: E205000: Too many arguments" -

c# - Copy ObservableCollection to another ObservableCollection -

All overlapping substrings matching a java regex -