Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

use pthread_atfork to make the runtime fork safe #9568

Closed
thestinger opened this issue Sep 27, 2013 · 5 comments
Closed

use pthread_atfork to make the runtime fork safe #9568

thestinger opened this issue Sep 27, 2013 · 5 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.

Comments

@thestinger
Copy link
Contributor

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

this would be excellent

@glycerine
Copy link

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
Copy link
Contributor

brson commented Sep 27, 2013

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

@thestinger
Copy link
Contributor Author

@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 thestinger mentioned this issue Oct 8, 2013
Closed
@thestinger thestinger mentioned this issue Oct 17, 2013
Closed
@thestinger
Copy link
Contributor Author

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.

@thestinger thestinger mentioned this issue Aug 27, 2014
Closed
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 6, 2022
@bors
Auto merge of rust-lang#9568 - matthiaskrgr:tools_util_bump, r=flip1995
8030ee9 
rustc_tool_utils: bump version in anticipation of a new release

cc rust-lang/rust-clippy#9553

After this is merged, I will publish the 0.2.1 version to crates.io, and make another PR that switches clippy to use the dependency from crates.io.
The source can still be kept in the clippy repo though imo.

This will allow miri and clippy to "share" the crate in the rustc repo once they both depend on it.

reopen of rust-lang#9561

changelog: release `rustc_tools_util` on `Crates.io`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@alexcrichton @brson @glycerine @thestinger