Skip to content

Cabal flag to control auto-labelling of threads #164

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

jasagredo
Copy link

Having this cabal flag allows the user to, on-demand, auto-label the async threads, pointing to the place where the async task is spawned. The idea is that the user then can go to the code/dependency and add a meaningful label to that thread.

Using CPP makes it transparent for users that don't want to opt-in to this behavior.

My idea is for this PR to be merged after #163. The first commit in this branch is the same as in #163.

@jasagredo jasagredo force-pushed the js/debug-auto-label branch from 6035549 to 5a7bd63 Compare January 24, 2025 15:53
@simonmar
Copy link
Owner

I'm open to the idea of labelling the internal threads - we now have two PRs for that (#162 and #163, I slightly prefer #162). But I'm not keen on adding auto-labelling functionality via cabal flags and CPP. Could you do this using a wrapper package async-labelled instead? It could use the same module name Control.Concurrent.Async so client code doesn't have to change.

@phadej
Copy link
Contributor

phadej commented Mar 26, 2025

Could you do this using a wrapper package async-labelled instead

That won't be ergonomic. If there's some other pakcage using async, you would need go and change it's .cabal file to use async-labelled; so broadly speaking some code would need to be changed.

Compared to adding --constraint="async +debug-auto-label" to cabal build command.

@jasagredo
Copy link
Author

I agree with @phadej. I think the functionality of auto labelling the threads is a very big win.

In terms of comparing #162 and #163, I think mine is more minimal as it labels internal threads. The other one does also label the threads the user spawns. That should usually be a task for the user who presumably would want different names for his actions.

Comment on lines 103 to 105
#ifdef DEBUG_AUTO_LABEL
HasCallStack =>
#endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would an alias work there? Like the following:

#ifdef DEBUG_AUTO_LABEL
import qualified GHC.Stack
#else
import qualified GHC.Exts
#endif
...
#ifdef DEBUG_AUTO_LABEL
type HasCallStack = GHC.Stack.HasCallStack
#else
type HasCallStack = () :: GHC.Exts.Constraint
#endif

That way one won't need to put ifdef in every single type signature.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure thing. I prioritized being explicit everywhere but what you suggest sounds good to me too.

@jasagredo
Copy link
Author

jasagredo commented May 29, 2025

I'm not sure if the suggested code works for as far back as 7.0.1 which is the one with base 4.3, and I don't know how I could test it or even if I can install such old versions still.

In particular it seems I need LANGUAGE ConstraintKinds and that one is available since 7.4.1, so probably not. But is it the case that the rest of the file does compile with such old compilers?

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.

4 participants