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

Liyang HU wrote:

On 24/11/06, Benjamin Franksen 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