-
Notifications
You must be signed in to change notification settings - Fork 84
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
Initial implementation of threadpool::Builder
.
#83
Conversation
src/lib.rs
Outdated
self | ||
} | ||
|
||
pub fn stack_size(mut self, size: usize) -> Builder { |
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.
todo: make this work
I would call it |
I chose Builder to match the one in the standard library https://doc.rust-lang.org/std/thread/struct.Builder.html |
Good point. I was thinking about the
let pool = Builder. ... set_pool_name("first name");
pool.execute( ... ); // Worker with the first name
pool.rename("some new name");
pool.execute( ... ); // once this job is scheduled the worker will rename itself I think, renaming a thread currently requires to spawn a new thread with the stable branch. |
src/lib.rs
Outdated
/// The three configuration options available: | ||
/// | ||
/// * `num_threads`: maximum number of threads that will be alive at any given moment by the built | ||
/// `ThreadPool` |
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.
Interesting ideas! I'm not sure what distinction you're making between the 'worker' and 'thread' names here. Are these ideas for this PR or could they be done in a follow-up PR? |
The renaming can be implemented later. I think it would only require the If I recall correctly I made the distinction to |
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 would prefer the constructing function to be reusable/non-consuming. In case somebody would like to create multiple pools with a similar configuration.
src/lib.rs
Outdated
/// .thread_stack_size(4_000_000) | ||
/// .finish(); | ||
/// ``` | ||
pub fn finish(self) -> ThreadPool { |
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.
Did you consider calling it build
or create
?
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 like build
. I'll change it to that
fair enough. added see anything else? |
/// .thread_stack_size(4_000_000) | ||
/// .build(); | ||
/// ``` | ||
pub fn build(self) -> ThreadPool { |
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.
pub fn build(&self) -> ThreadPool
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.
that would cause unnecessary allocations. if the user needs to build another threadpool Builder
(most do not), they can just call clone
on the Builder
.
After thinking about it a bit more, leaving the I don't have a strong opinion on Apart from that: 👍 looks very good to me. Thank you! |
this is what the code looks like if we changed diff --git a/src/lib.rs b/src/lib.rs
index 6a78abf..a889008 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -278,13 +278,13 @@ impl Builder {
/// .thread_stack_size(4_000_000)
/// .build();
/// ```
- pub fn build(self) -> ThreadPool {
+ pub fn build(&self) -> ThreadPool {
let (tx, rx) = channel::<Thunk<'static>>();
let num_threads = self.num_threads.unwrap_or_else(num_cpus::get);
let shared_data = Arc::new(ThreadPoolSharedData {
- name: self.thread_name,
+ name: self.thread_name.clone(),
job_receiver: Mutex::new(rx),
empty_condvar: Condvar::new(),
empty_trigger: Mutex::new(()), this means that if someone did |
Ah, good point. I did not think of that. Merge? |
bors r+ |
bors r+ |
bors r+ |
bors ping |
bors r+ Can I talk to bors too? |
You should be able to, but it's not working. Probably related to moving this repo from @frewsxcv's account to the organization. |
bors r+ |
1 similar comment
bors r+ |
Timed out |
bors retry |
Has AppVeyor been turned on yet? |
bors r+ |
@notriddle That was it. Appveyor didn't track the rename so it was not longer enabled. Wonder if there's a better way to handle this, maybe bors should add a comment |
I know what bors needs to do to handle the rename, roughly speaking. And I can't fix AppVeyor. |
Related to #77.