@RichFelker http://austingroupbugs.net/view.php?id=1201 … You can't have a process atomically unmaks a signal *and* wait can you? Normally there is a loop-and-retry pattern, or the child's signal ends in process termination. Feels like Monday :-)
The best treatment of this issue I'm aware of is here: https://stackoverflow.com/a/40900621/379897 … Personally I think it's an error/omission in the spec that atomicity is not explicitly required; it's obviously intended.
-
-
I think the analysis is wrong, both glibc and the kernel do not do this task atomically. They unmaks the signal and then wait.
-
I think your analysis is wrong. Signals can't asynchronously interrupt kernelspace. They're handled when returning from kernelspace to userspace.
-
Yes, of coarse you're right, I wasn't thinking straight. If you are also in a secenario where you have multiple threads then the design pattern has to be completely different.
End of conversation
New conversation -
-
-
It might be possible, however, to emulate the intended behavior of sigsuspend using sigwaitinfo (consume the signal then manually call the signal handler with the consumed info).
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.