4 ms·
Being async-safe just means you can call it in a signal handler, and is unrelated to being thread safe. _exit() will cause a similar race condition, but probab
by noselasd 10y ago
Being async-safe just means you can call it in a signal handler, and is unrelated to being thread safe.
_exit() will cause a similar race condition, but probably with less severe effects. _exit() closes all open file descriptors (not FILE*, like exit() does).
That means while exit() is executing, another thread could perform a file operation on a file descriptor that just was closed by the other thread running exit(). imo. glibc exit() implementation should halt/pause all the other threads before it goes on to mess with shared resources before it terminates the process.
- mzs 10y agolook here: http://lxr.free-electrons.com/source/kernel/exit.c?v=3.12#L915 http://lxr.free-electrons.com/source/kernel/exit.c?v=3.12#L9... Conceptually all that you described (plus some more, thing SysV IPC and MM) happens in the kernel (although the behaviour of streams is not specified, I can't think of any OS that does more than close FDs) after the OS has made it so every thread in the process can't go forward. I alluded to the misfeature in glibc, that's why you used to have to do raise(9) on linux to work around the oddity. Every other OS just did the right thing (though you sometimes had to build or link your program differently), ie all threads are 'stopped' before any of the things like closing FDs happens.
- deleted 10y ago[deleted]