-
Notifications
You must be signed in to change notification settings - Fork 585
windows-threading: Implement scope for Pool
#3696
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
Conversation
Send for windows_threading::Poolscope for Pool
|
Ok, looking at this more I do think we need a scope API to ensure this is robust so I've changed this PR to implement that, While investigating this (and part of what drove this conclusion) I found that the service threading sample is not technically sound. Specifically these lines: windows-rs/crates/samples/services/thread/src/main.rs Lines 16 to 20 in 897ea82
I think this requires changes in the service API to support either a reference counted |
c627ff6 to
191d1b1
Compare
| let service_original = Arc::new(RwLock::new(Service::new())); | ||
| let service = Arc::clone(&service_original); | ||
| service_original |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems overly complicated. The original Service::run terminated the process upon completion so that the run method was -> ! and the lifetime was much simpler. This was changed in #3662 to make it possible to test Service but perhaps that was a mistake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or the Service::run needs a similar scope pattern?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it might be better (and simpler) to separate Service into two: one that constructs the service and another that accesses it afterward. The latter could then be freely moved, cloned, etc because it's just accessing global state (via appropriate locks).
Using the scoped pattern may be another option. I'm still not sure if that'd be more or less ergonomic though. It does need to be able to call the closure multiple times which complicates things. It might help if run consumed self rather than taking &mut self. I'd want to play about with this a bit more to see.
|
I definitely found a friction between Rust's lifetime model and the various restrictions in the threadpool APIs. I much prefer the addition of the |
|
I played around with this today - I don't love how this impacts |
|
I've been thinking a lot about the Service API and yeah, I don't love the workaround in this PR. It does need changes to the Service API itself but I'd be happy to leave that to follow up work. |
This is a fix #3695 that adds a
scopeAPI.