Liyang HU wrote: > On 24/11/06, Benjamin Franksen <[EMAIL PROTECTED]> 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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
