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

Do not migrate tasks to a different thread pool #32

Merged
merged 1 commit into from
Mar 12, 2024

Conversation

samtkaplan
Copy link
Contributor

@samtkaplan samtkaplan commented Mar 11, 2024

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, if try_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.

Change the try_with_timeout method so that it does not migrate
a task to a different thread pool.
Copy link
Member

@quinnj quinnj left a 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!

Copy link

codecov bot commented Mar 11, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.24%. Comparing base (89c13cc) to head (f632270).

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.
📢 Have feedback on the report? Share it here.

@@ -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))
Copy link
Member

@quinnj quinnj Mar 11, 2024

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?

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.

@quinnj quinnj merged commit f6bdb95 into JuliaServices:main Mar 12, 2024
5 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants