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.

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

Publish this crate in a new name #3

Closed
NobodyXu opened this issue Aug 31, 2022 · 5 comments
Closed

Publish this crate in a new name #3

NobodyXu opened this issue Aug 31, 2022 · 5 comments
Assignees
Labels
help wanted Extra attention is needed

Comments

@NobodyXu
Copy link
Member

NobodyXu commented Aug 31, 2022

I'd plan to publish this crate in a new name and submit a PR to cc and other dependents to use this crate, which contains various fix and performance optimization (it can use posix_spawn on unix, which could use vfork instead of fork).

What name should we use?
And is there anything we need to be careful?

@NobodyXu NobodyXu added the help wanted Extra attention is needed label Aug 31, 2022
@passcod
Copy link
Member

passcod commented Sep 1, 2022

I guess there's one question here and it's, can we achieve the same purpose as our fork but by depending on jobserver proper, as Crichton originally suggested, or not, in which case we can treat the original thread at the origin of this fork as a decent signal that a full fork is not unwelcome.

Then, naming. We could go the usual boring fork naming scheme of e.g. cargobins-jobserver.

We could also decide to go for different but related name. For example I note that the general concept in make is called "Job Slots", so we could use jobslots.

Finally, we could iterate on that a bit and go for a punny name in fine software / rust tradition, perhaps slotmachine (leaning into "slots") or busboy (leaning into "server")

@NobodyXu
Copy link
Member Author

NobodyXu commented Sep 2, 2022

can we achieve the same purpose as our fork but by depending on jobserver proper

rust-lang#25 is wontfix and even valid use of jobserver could end up causing process::Command::spawn to fail.

This problem is unfixable on windows because it does not support pre_exec handle.

Also, jobserver uses pre_exec handle on unix, which means that process::Command::spawn cannot use posix_spawn, which might be able to use vfork to reduce latency and avoid memory overcommitment.

in which case we can treat the original thread at the origin of this fork as a decent signal that a full fork is not unwelcome.

From rust-lang#40 (comment) :

Yes I understand it's the API itself that's causing the issue. This is so significantly different from before that I don't want to pull it into this crate. If you'd like though you could maintain a separate crate which depends on this one.

As for the naming, I think jobslots sounds great and make it clear what this crate is for.

@passcod
Copy link
Member

passcod commented Sep 2, 2022

jobslots it is!

@NobodyXu
Copy link
Member Author

NobodyXu commented Sep 2, 2022

jobslots it is!

I will submit a PR to change the name and version, and update other metadata.

@NobodyXu
Copy link
Member Author

NobodyXu commented Sep 9, 2022

I've published v0.2.0!
Due to problem with the doc, I will publish v0.2.1 soon though.

And @passcod I have sent an invitation for you to join https://crates.io/crates/jobslot to reduce the bus factor.

@NobodyXu NobodyXu closed this as completed Sep 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants