-
Notifications
You must be signed in to change notification settings - Fork 26
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
use of noidle with MPD monad #99
Comments
You can get the handle via I'd like to be able to run computations against a connection object, but that'd require some reshuffling ... |
I'm leaning toward that option. The sticky aspect of this for me is that |
Special casing would be in line with the protocol, so that makes sense. |
In that case, it might also make sense to change the type signatures on |
My only concern would be complexity, but then I think something like this is probably required given the base design. Will be easier to evaluate if/when there is code to implement the feature. |
See https://github.com/joachifm/nanompd/blob/master/src/MPD/Core.hs#L90 for a simpler base approach, which I believe is much easier to work with (normal async should Just Work), though it shifts more responsibility onto the client implementor. |
I've been attempting to write a client layer on top of the
MPD
monad that only uses a single connection to communicate. I'm not sure this is possible if oneidle
s, and am looking for clarification. It appears as though theMPD
monad effectively doesn't support thenoidle
command, asidle
blocks the thread, and the monad provides no way to access the underlying socket handle from the outside. Am I correct in assuming that to do this properly, one needs to write an alternative, concurrency-orientedMonadMPD
implementation? I am somewhat new to GHC's concurrency support, and wonder if I may be overlooking a potential solution.The text was updated successfully, but these errors were encountered: