4 ms·
I think the actual problem here is that fork has a bad API that is easy to misuse accidentally; and when something can go wrong, it eventually will go wrong. R
by chousuke 7y ago
I think the actual problem here is that fork has a bad API that is easy to misuse accidentally; and when something can go wrong, it eventually will go wrong.
Raising awareness about bad APIs will also help people realize when they're about to create one themselves, which might cause them to switch designs.
- ColanR 7y agoFork has an extremely standard API, and that's a good thing. What needs to be quantified is how much ignorance a programmer can be expected to have, before errors they make are their own responsibility.
- chousuke 7y agoThe API being "standard" doesn't change it being bad. I mean, it is what it is and probably couldn't have been much better given historical reasons, but I think it's still useful to think on how it fails and how to improve on it.
- ColanR 7y agoAt the low level of C and Unix, text is the language of the API. Something has to be that low-level - either the OS and the language it's written in, or the extra level of abstraction supporting the OS and its implementation language (in which case the complexity is much higher, and a lot more bugs would be exposed). Either way, there's going to be some point in the layers of abstraction where these kinds of errors are possible. I'm not seeing how an overall improvement could be made to the API without adding abstractions. To me, it seems better that there are fewer layers so that the architecture is clear, the elements of the OS and language are known, and the points where such errors are possible are clearly marked - as was done in this article submission.