[Haskell-cafe] Re: [Haskell] Re: SimonPJ and Tim Harris explain
STM - video
haskell.org at liyang.hu
Thu Nov 23 20:21:03 EST 2006
On 24/11/06, Benjamin Franksen <benjamin.franksen at bessy.de> wrote:
> > 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
> [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.
More information about the Haskell-Cafe