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

Add an API for 'named services' #3204

Closed
brson opened this issue Aug 15, 2012 · 3 comments
Closed

Add an API for 'named services' #3204

brson opened this issue Aug 15, 2012 · 3 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@brson
Copy link
Contributor

brson commented Aug 15, 2012

We currently have two global tasks that are started on demand and run until the process ends. The memory profiler that digitalknight is working on will add another. Each of these must deal with an ugly unsafe API, and they each create their own scheduler, threads, native stacks, etc.

It would be nice to have a safe API for this that allows services to be named (possibly like the TLS does) and that lets all services share a single scheduler. Services would still need an option to create their own scheduler though, as uv does need its own.

I imagine this would work by having just a single 'named service service' use the current unsafe API, and letting it in turn be responsible for managing the service lifecycle.

It would also be good to come up with a way to let services be stopped when not in use.

@brson
Copy link
Contributor Author

brson commented Jul 9, 2013

This type of global task should not be required in the new scheduler, so may be out of scope for std.

@brson
Copy link
Contributor Author

brson commented Jul 9, 2013

Un-nominating.

@graydon
Copy link
Contributor

graydon commented Jul 11, 2013

no compelling use cases at this point, closing WONTFIX

@graydon graydon closed this as completed Jul 11, 2013
RalfJung pushed a commit to RalfJung/rust that referenced this issue Dec 3, 2023
jaisnan pushed a commit to jaisnan/rust-dev that referenced this issue Jul 29, 2024
GitHub closed the previous PR (rust-lang#3205) after I renamed a branch, hooray.

Change the implementation of `println!` & `eprintln!` with no arguments
to call `print!("\n")`
& `eprint!("\n")` respectively instead of producing no tokens. This is
what std does. [^println][^eprintln]

 
[^println]:
https://github.com/rust-lang/rust/blob/8c127df75fde3d5ad8ef9af664962a7676288b52/library/std/src/macros.rs#L140
[^eprintln]:
https://github.com/rust-lang/rust/blob/8c127df75fde3d5ad8ef9af664962a7676288b52/library/std/src/macros.rs#L218

Resolves rust-lang#3204.

A test included, as per
model-checking/kani#3205 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

2 participants