-
Notifications
You must be signed in to change notification settings - Fork 5
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
Do not migrate tasks to a different thread pool #32
Conversation
Change the try_with_timeout method so that it does not migrate a task to a different thread pool.
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 is a great catch; thanks for digging into this and proposing the fix!
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #32 +/- ##
==========================================
+ Coverage 89.86% 90.24% +0.38%
==========================================
Files 8 8
Lines 365 369 +4
==========================================
+ Hits 328 333 +5
+ Misses 37 36 -1 ☔ View full report in Codecov by Sentry. |
@@ -4,6 +4,14 @@ export Lockable, OrderedSynchronizer, reset!, ReadWriteLock, readlock, readunloc | |||
Workers, remote_eval, remote_fetch, Worker, terminate!, WorkerTerminatedException, | |||
Pool, acquire, release, drain!, try_with_timeout, TimeoutException | |||
|
|||
macro samethreadpool_spawn(expr) | |||
if isdefined(Base.Threads, :threadpool) | |||
esc(:(Threads.@spawn Threads.threadpool() $expr)) |
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.
@kpamnany, do you know why Threads.@spawn
doesn't do this by default?
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.
The thinking was that the default behavior should be to spawn to the default thread pool and you need to explicitly spawn an interactive task because they have an implicit contract to not hog the CPU. For backward compatibility, the contract cannot be assumed.
This change ensures that the
try_with_timeout
method runs its task on the same thread pool that that it is executed from. For example, iftry_with_timeout
is called from an interactive thread, then it is a good guess that we want the function being run to also execute in the interactive thread pool, and not the default thread pool.This is one half of a fix for HTTP.jl#1153.
I will make another pull request to HTTP.jl with the other half of the fix.The other half of the fix is JuliaWeb/HTTP.jl#1159.