Rename ThreadPool::as_worker() to with_worker()#15
Rename ThreadPool::as_worker() to with_worker()#15NthTensor merged 2 commits intoNthTensor:mainfrom BD103:with-worker
ThreadPool::as_worker() to with_worker()#15Conversation
|
Sweet, thank you so much! I agree, this name is not ideal. I'm still getting the project online a bit, so this will be blocked until I fix CI. |
NthTensor
left a comment
There was a problem hiding this comment.
CI is now fixed, but I've made some changes to the tests so you will have to rebase.
|
Ok, it should be all good now! When fixing the conflicts, I ran into this comment: Lines 633 to 637 in ae7aa8f Specifically, this bit:
I combined it into:
|
|
Yep, artifact of an older design. I need to do a pass on the docs, there's a few places where I may have left outdated stuff. Thanks for catching that one. |
The docs of
ThreadPool::as_worker()describe it as a potentially expensive operation. However, theas_prefix usually signals a cheap and quick operation (see the Rust API Guidelines and examples such asstr::as_bytes()andpointer::as_ref()). This can be a problem, as someone reviewing code may assumeas_worker()is a cheap operation and not realize it could cause a mutex lock.This PR renames
as_worker()towith_worker(), in a similar vein toLocalKey::with()and the oldTaskPool::with_local_executor(). Not only does thewith_prefix signal that it will pass a worker to a closure, but it also doesn't come with any assumptions on its performance.This is a breaking change, although I'm not sure how you want to document it.