Comment by cryptonector
4 years ago
> 'It's not a footgun, just don't make mistakes.'
fork() -> fork bombs -> fork() is a footgun!
You have to know how to use it. Yes. So what?
> Like I've said elsewhere in the comments, I've literally had to fix awful bugs, some security related, from how much vfork() is a preloaded foot gun with the safety off. Not everyone who has a bad impression of it is just following the "lore".
Links or it didn't happen :)
> fork() -> fork bombs -> fork() is a footgun!
> You have to know how to use it. Yes. So what?
No, you have to own everything that you could call. For one example of many, are you in and out of a library that longjump's? That's really fun.
Basically vfork's sharing of the full on mutable stack between the parent and child is full on bananers.
> Links or it didn't happen :)
You know that some people write proprietary code, even for unixen, right?
> No, you have to own everything that you could call. For one example of many, are you in and out of a library that longjump's? That's really fun.
That is also true of fork().
You're supposed to only use async-signal-safe functions on the child-side of fork().
It is surprisingly easy to do dumb things with fork().
> You know that some people write proprietary code, even for unixen, right?
I was hoping it was in open source code.
> That is also true of fork().
> You're supposed to only use async-signal-safe functions on the child-side of fork().
Not practically, there's way more code out there designed day one for fork(). Next to none designed for vfork() explicitly.
Signal safety has more to do with shared mutability, which isn't a concern for fork. You can get into gross situations mixing fork and threads, but that's equally true of vfork.
4 replies →