use pthread_atfork to make the runtime fork safe

[thestinger]

jemalloc already does this, so we don't have to worry about malloc and free.

[glycerine]

this would be excellent

[glycerine]

other approach would be to just have the runtime not start more than one thread, ever. This would be much saner actually, since user code that grabs locks is almost impossible to modify to make it fork safe. #9373

Obviously single-threaded everything isn't what is wanted in the general case where you do want to exploit multiple cores, but it would be nice to have the option for code that wants to use tradition daemon style fork-ing.

[brson]

what would the runtime do to be fork-safe? this seems very difficult.

[thestinger]

@brson: I'm not sure if it would be feasible, but in theory we can register handlers with pthread_atfork to re-initialize a fresh runtime in a new process. I don't think it's very important, so it might be too difficult to be worth the trouble.

The old system for handling daemons was for the end of the first child to signal that initialization was done, but this has been superseded by socket activation in systemd, upstart and launchd.

[thestinger]

I think the option of using #![no_std] with libcore is fine. Rust does need to provide an I/O and concurrency library at a lower level than the full blown runtime, but I think that's inevitable.