4 ms·
One thing that might have been nice to note is the rules regarding what you can and can't do in signal handler code.
by throw7 11y ago
One thing that might have been nice to note is the rules regarding what you can and can't do in signal handler code.
- JoeAltmaier 11y agoOne of my pet peeves: documentation that doesn't say anything. Methods (and callbacks) are listed by name with some thrifty description of argument. But none of the important stuff is ever there: is it reentrant? stateless? Who owns each non-scalar argument? Can it be invoked from user space? installable driver? kernel driver? Signal handler? Does it have latency constraints? Can I use it from a different thread than it was constructed under? Is it protected during thread death? Is it atomic vs what other methods? What other apis are allowed/forbidden when writing a callback? As an embedded programmer, I end up reading library source most of the time trying to find these answers. And if it isn't open, then I have to black-box test or lard calls up with semaphores which might not be necessary. The state of API documentation is in the stone age.
- marios 11y agoThe short answer is: not much. Basically change a global variable declared as volatile sig_atomic_t. You can find more information in this presentation [1] (from 2004!). [1]: http://www.openbsd.org/papers/opencon04/index.html http://www.openbsd.org/papers/opencon04/index.html