-
Notifications
You must be signed in to change notification settings - Fork 16
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
Apply thread labels to internal worker threads #305
Comments
How would this work with |
|
Gentle ping. From my perspective this proposal is ready for a vote. |
Is there anything I can do to move this along? I would very much appreciate being able to get this off my desk. |
@Bodigrim, what's the next step? |
(Sorry, I'm massively overwhelmed for the past month or so) Related discussion:
@tomjaguarpaw following the Reddit discussion, do you have any specific concerns about the proposal at hand? I understand that you are somewhat unhappy about the existence of |
I agree. I don't see the labels themselves as a problem. This proposal is fine by me. |
Dear CLC members, let's vote on the proposal to annotate internal worker threads in @tomjaguarpaw @velveteer @mixphix @hasufell @angerman @parsonsmatt +1 from me. |
+1 |
2 similar comments
+1 |
+1 |
Thanks all, that's enough votes to approve. |
Various functions in
base
are implemented via the use of auxiliary threads. Recently a user requested that GHC apply thread labels to these threads to make these threads clearly identifiable in the event log andlistThreads
output.Specifically, I propose that the following functions' implementations be augmented with thread labels where appropriate:
Control.Concurrent.threadWaitRead
Control.Concurrent.threadWaitWrite
Control.Concurrent.threadWaitReadSTM
Control.Concurrent.threadWaitWriteSTM
System.Timeout.timeout
GHC.Conc.Signal.runHandlers
The proposed thread labels are static and consequently should have negligible impact on runtime.
Implementation: !13566
The text was updated successfully, but these errors were encountered: