Hi,
> After seeing how close I could come to creating onRetry/retryWith I have a
> question about the semantics of your idea for retryWith.
>
> Normally after a retry the STM block is rolled back and put to sleep and
> will
> only be awakened and re-executed if one of the STM variables it had read
> from is
> committed to by a different STM block.
>
> What about retryWith ? Will the STM block be put to sleep under the same
> conditions? Can the IO action given to retryWith include commits to STM
> variables?
Starting with this last question -- yes, the example of an STM GetLine using
retryWith to pull more input into a buffer relies on an atomic block in the IO
action to update the buffer.
There are some interesting questions to think about the semantics of
"retryWith". The semantics of "retry" in the PPoPP paper say nothing about
putting threads to sleep -- it would be correct for an implementation to spin
repeatedly executing an "atomic" block until it completes without calling
"retry". What should happen with "retryWith" -- should we introduce blocking &
wake-up into the semantics, or say that the "retryWith" actions are collected
together, executed in place of the transaction (if it does ultimately retry)
and then the transaction re-attempted? For simplicity (and to leave
flexibility to the implementation) I'd prefer to keep blocking & wake-up out of
the semantics.
Taking that option, suppose we have "atomic { X }" and X retries with IO action
Y. I think I'm saying that that would be equivalent to "Y ; atomic { X }".
What are the consequences of this? In the GetLine example it means that an
implementation that does put threads to sleep must detect conflicts between the
first execution of X and any transactions performed in Y.
Are there any interesting problems that come up if "Y" performs transactions
that use "retry" or "retryWith"?
Tim
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
