4 ms·

I cannot upvote this enough. I've written some rust code which uses fork, and after reading this, I went to check the docs. And lo and behold it follows the con

I cannot upvote this enough. I've written some rust code which uses fork, and after reading this, I went to check the docs. And lo and behold it follows the convention you put forth. So I was safe. Yay Rust, where things either fail (panic and quits the program) or returns a result that you can't use until you check for the error.

the8472 7y ago
> So I was safe. Fork (without exec) is a very sharp tool because it can violate ownership, doubly so in multi-threaded programs. So just because you get a Result from it doesn't mean all its pitfalls are handled.
- bluejekyll 7y ago
  It’s true, though the FD_CLOEXEC flag generally helps in this area. Recently though I had to remove a bunch of these safeguards because I wanted to share handles and such across processes. So sometimes it’s nice to have that feature.
- hinkley 7y ago
  Correct me if I'm wrong, but isn't there a problem with mutex sharing as well?
  - the8472 7y ago
    I was using a wide definition of "ownership". Parent and child unintentionally sharing a mutex is one manifestation of those issues.
- tedunangst 7y ago
  Note that posix says you shouldn't do anything except immediately call exec after fork in multithreaded programs.
  - klodolph 7y ago
    This is not true. IIRC, you can do anything as long as you don’t call any function which is not async signal safe. Otherwise, it would be very difficult to do simple things like run a child process in a separate directory (with chdir()), or report a failed exec() to the parent. The typical way to report errors upwards is to create a pipe with CLOEXEC and then write the error code to it from the child if exec fails. This requires at least calling write(). You may be remembering vfork(), which is a bit of an obsolete API.
    - tedunangst 7y ago
      Ah, yes, I overstated the case. Thanks for clarifying the rule is only signal safe functions. Notably, this excludes malloc, etc. (I was thinking as I posted I should dig up the relevant quote just to be sure. Oops.)

the8472 7y ago

> So I was safe. Fork (without exec) is a very sharp tool because it can violate ownership, doubly so in multi-threaded programs. So just because you get a Result from it doesn't mean all its pitfalls are handled.

bluejekyll 7y ago
It’s true, though the FD_CLOEXEC flag generally helps in this area. Recently though I had to remove a bunch of these safeguards because I wanted to share handles and such across processes. So sometimes it’s nice to have that feature.
hinkley 7y ago
Correct me if I'm wrong, but isn't there a problem with mutex sharing as well?
- the8472 7y ago
  I was using a wide definition of "ownership". Parent and child unintentionally sharing a mutex is one manifestation of those issues.
tedunangst 7y ago
Note that posix says you shouldn't do anything except immediately call exec after fork in multithreaded programs.
- klodolph 7y ago
  This is not true. IIRC, you can do anything as long as you don’t call any function which is not async signal safe. Otherwise, it would be very difficult to do simple things like run a child process in a separate directory (with chdir()), or report a failed exec() to the parent. The typical way to report errors upwards is to create a pipe with CLOEXEC and then write the error code to it from the child if exec fails. This requires at least calling write(). You may be remembering vfork(), which is a bit of an obsolete API.
  - tedunangst 7y ago
    Ah, yes, I overstated the case. Thanks for clarifying the rule is only signal safe functions. Notably, this excludes malloc, etc. (I was thinking as I posted I should dig up the relevant quote just to be sure. Oops.)