4 ms·
Thinking about it some more, one problem would be what to do with threads that have just called a system call and are waiting for a response. To have both pare
by mhandley 9y ago
Thinking about it some more, one problem would be what to do with threads that have just called a system call and are waiting for a response. To have both parent and child process system calls complete without errors would require cloning the kernel state, and that's not trivial. It some cases, there's probably no good answer, short of causing one of the two system calls to return an error, and that in itself would confuse a lot of user-space software. I suppose you could return something similar to EAGAIN, but you'd be dependent on user-space handling that cleanly. Maybe you could hide this under libc?
- wruza 9y agoEINTR? I suspect some calls are defined to never return it, but it may be just de facto, not strict rule. Edit: simply signalling all threads with SIGFORK, waiting for a handler to return and freezing a thread at SA_RESTART point feels right way to do it. Why did POSIX decide to fork() only one thread by default at all?
- crest 9y agoBecause the alternatives are worse.
- ScottBurson 9y agoSo this is a worse-is-better design decision driven by a previous worse-is-better design decision. If system calls were interruptible, then the problem of threads in system calls would go away.