Hallo,
On 24/11/06, Benjamin Franksen
So, you could simply return the console output as (part of) the result of the atomic action. Wrap it in a WriterT monad transformer, even. But this would break atomicity, wouldn't it?
In the sense as you just described, yes. You're right: there's no guarantee that something else might not jump in between the call to atomic and the following putStr, so the TVar changes in the atomic block no longer take place in step with the output actions.
I have a pretty good idea how much data is going to be produced by my own code, and if it's a bit more than I calculated then the whole process merely uses up some more memory, which is usually not a big problem. However, with input things are different:
Really? I'd have said that I have a pretty good idea how much data is going to be consumed by my own code, and if it's a bit more than I calculated then I'd merely read some more at the beginning (putting any unused bits back on the input queue afterwards of course), which is usually not a big problem. :) Yes, I do get your point. It's easier to allocate a larger buffer for your output as needed, than to anticipate how much input you might require. I'd still claim they're different instances of the same scheme though!
[If] I still haven't got enough data, my transaction will be stuck with no way to demand more input.
Take your output channel idea, and use that for input too? (Separate thread to read the input and place it at the end of some queue.) You would basically retry and block (or rather, STM would do the latter for you) if you haven't enough data, until more came along. Cheers, /Liyang