5 ms·
Or a signal handler? Even if there's a single kernel thread, if it can be interrupted while inside one of these functions you can hit the same sort of problem.
by kimixa 2y ago
Or a signal handler? Even if there's a single kernel thread, if it can be interrupted while inside one of these functions you can hit the same sort of problem.
Reentrancy was an issue on consumer devices well before multithreading was commonly supported there, after all
- rdtsc 2y agoGood point. There are multiple levels of "safety". I think glibc API does a decent job marking and indicating which is which: https://sourceware.org/glibc/manual/2.40/html_node/POSIX-Safety-Concepts.html https://sourceware.org/glibc/manual/2.40/html_node/POSIX-Saf... Thread-Safe Async-Signal-Safe Async-Cancel-Safe (mostly limited to pthread_*cancel*) There is a host of other "safety" remarks also useful to keep in mind: https://sourceware.org/glibc/manual/2.40/html_node/Other-Safety-Remarks.html https://sourceware.org/glibc/manual/2.40/html_node/Other-Saf...
- kragen 2y agothis isn't about safety, though; hcreate() and hsearch() don't support having two hash tables in the same process at the same time, not even in an unsafe way. that also makes them non-reentrant, but that isn't the main problem!