-
Notifications
You must be signed in to change notification settings - Fork 696
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
Make notice/warn/debug and friends thread safe #4357
Comments
I actually implemented something like that for the first version of /cc @dcoutts |
If we put the loggers in |
IMO it would make sense to rename |
Personally, I think it might make more sense to do an MTL-style approach where we have a thin wrapper over IO which grants whatever capabilities are needed in any given piece of "IO" code... but then Verbosity is already plumbed into most places where we do any output[1], so it definitely seems like the least intrusive solution currently. The MTL-style approach has the admittedly very-long term advantage that we could start limiting other things (such as e.g. subprocess creation) with further "capability classes") which would make the code a lot more manageable. (See also #4126) |
I too would really like to see Cabal have some more monads (though, I quite like concrete but abstract monads ;-) But this would basically involve churning the entire codebase, and there's never quite a good time to do that... (it's even worse for Cabal library since everything stops being BC.) |
Yeah, agreed. Though, I was thinking that a slow migration might be feasible with MTL-style type classes... (But Cabal would become... 'interesting'.). Realistically it's probably at least a year or two (calendar time) of effort, I should imagine. AFAICT the |
I looked into fixing this to solve #4376 but one thing that struck me is that we probably want to have some global mutable state anyway, to serve as the lock between instances by default. Otherwise, we'll have the unenviable task of tracking down all the places where we generate up a default verbosity and tagging them correctly. (I guess global mutable state doesn't feel too bad here, because stderr and stdout are "global state"?) I wonder what people think... |
Just a note to self: See also https://www.fpcomplete.com/blog/2017/07/the-rio-monad for potential simple solution for the "break everything" problem. |
This problem, i.e. terminal output getting garbled/interleaved, is still present in The problem is not present with The issues #3075, #5756, #4838, #4376 (all open) seemingly describe the same problem. Illustration
Full output:
The above run was performed on a simple example project basically identical to the default project, but with two test suites. Versions used: cabal --version
# cabal-install version 3.12.1.0
# compiled using version 3.12.1.0 of the Cabal library
uname -mrsv
# Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:16:51 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T8103 arm64 |
@LeuschkeTressa thanks a lot for rehashing the problem! Indeed, it's embarrassing to not use thread-safe IO in 2024. No one is currently working on this, to my knowledge, so we'd welcome contributions in this field very much! |
At the moment, they are only as thread safe as a call to hPutStr is; in other words, not very.
The best way to fix this without introducing global mutable state is to finally implement the logging infrastructure for Verbosity that I've been muttering about:
The text was updated successfully, but these errors were encountered: