[Haskell-cafe] Re: Re: [Haskell] Re: SimonPJ and Tim Harris explain STM - video

[Benjamin Franksen]

Liyang HU wrote:
> On 24/11/06, Benjamin Franksen <benjamin.franksen at bessy.de> wrote:
>> 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.

Right. I couldn't see it at first but the I and O really are dual to each
other. Thanks for pointing this out -- it seems STM is even more useful
than I thought.

Cheers
Ben