4 ms·
*...it's a total mess...theoretically it's possible....speculation on standard behavior based on platform behavior...namespace(x)<-threads->chosen implementati
by jankedeen 9y ago
*...it's a total mess...theoretically it's possible....speculation on standard behavior based
on platform behavior...namespace(x)<-threads->chosen implementation detail...functional language reference...
-- Translation: Design is broken
- klodolph 9y agoWell, then allow me to cite the standard for you. > If a multi-threaded process calls fork() ... the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. IEEE Std 1003.1-2008, 2016 Edition http://pubs.opengroup.org/onlinepubs/9699919799/ http://pubs.opengroup.org/onlinepubs/9699919799/ I don't know about "design is broken". I personally think the fork()/exec() model is a clumsy way to create a new process, but that's a matter of taste.
- jankedeen 9y agoThe preferred model with fork() in a thread is to exec as quickly as possible. Otherwise pthread_atfork can be prepared given adequate design: http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html http://pubs.opengroup.org/onlinepubs/009695399/functions/pth... If you have work to do in the thread do these in the thread. If you must fork() then exec. Signal safety in pthreads can be handled generally via the pthread_sigmask|queue family. The corresponding facility in processes is similarly known. Yes, the conditions you posit exist but they are the product of bad development imho. You have provided badly designed examples and worst case scenarios while noting that you dislike the unix model for process inception. Great. Now go away. You know enough to be dangerous.