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

Don't suspend schedulers if terminating and reset steal_attempts on wake #2447

Merged
merged 1 commit into from
Dec 25, 2017

Conversation

dipinhora
Copy link
Contributor

Prior to this commit, a scheduler thread could potentially suspend even
if it was supposed to be terminating. This commit makes it so that it
only goes down the suspend path if the thread is not terminating.

Additionally, we now set steal_attempts = 0 on waking from a suspend
to ensure that the scheduler thread will try to steal from all other
threads prior to suspending again.


@winksaville In theory, this might fix #2445 if somehow a scheduler thread was being suspended again after being woken when it should have terminated instead.

Prior to this commit, a scheduler thread could potentially suspend even
if it was supposed to be terminating. This commit makes it so that it
only goes down the suspend path if the thread is not terminating.

Additionally, we now set `steal_attempts = 0` on waking from a suspend
to ensure that the scheduler thread will try to steal from all other
threads prior to suspending again.
@SeanTAllen
Copy link
Member

@winksaville can you test this to see if you still end up with the #2445. If you don't, I'll do a 0.21.2 release to get this out.

@SeanTAllen
Copy link
Member

Thanks @dipinhora

@winksaville
Copy link
Contributor

winksaville commented Dec 25, 2017 via email

winksaville added a commit to winksaville/ponyc that referenced this pull request Dec 25, 2017
…:ponylang/ponyc into support-openssl1.1-simple-travis

Test PR "Don't suspend schedulers if terminating and reset
steal_attempts on wake" ponylang#2447
@winksaville
Copy link
Contributor

I'm now running a test that includes this change, the prior run hung after 40minutes. My test, which runs stdlib --sequential in a loop forever and has typically failed in less than an hour. We'll see what happens.

@winksaville
Copy link
Contributor

After 4 plus hours still no hang, I declare it "fixed" and we should take this change.

@SeanTAllen SeanTAllen merged commit d46707f into ponylang:master Dec 25, 2017
@SeanTAllen SeanTAllen mentioned this pull request Dec 25, 2017
@SeanTAllen
Copy link
Member

Thanks for testing @winksaville

SeanTAllen added a commit that referenced this pull request Dec 25, 2017
Forgot to add before merging.
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.

Running stdlib in a loop can hang
3 participants