On 12/5/06, Chris Kuklewicz <[EMAIL PROTECTED]> wrote:
Making small programs to test these properties is a good sanity check. For instance I just leaned that "safePoint = unblock ( return () )" does not work.
Maybe if you do something to allocate some memory inside of the unblock?
> If this were true, then if you caught an asynchronous exception from > the putMVar operation, you'd know that a value was not put into the > MVar by the operation. I think that should be a safe assumption when running under "block".
"I think" and "should be" is nice, how do we find out if it's really true -- for sure?
> Then it would be easy to program with MVar's in the presence of > asynchronous exceptions. When you caught an asynchronous exception, > you could set a flag, and then redo the putMVar. If you call that "easy" then sure. > For STM, is "atomically" an interruptible operation? If it is, what > guarantees does it offer in the presence of asynchronous exceptions? "block (atomically stm)" is interruptible when the operation "stm" uses retry and perhaps when it has to be re-attempted due to conflicting updates. If it runs without conflict and commits then it cannot be interrupted by an async exception. If (atomically stm) is interrupted then it is rolled back and will have had no visible side effects.
Easy in the sense that the pattern of "trying an operation, setting a flag if an asynchronous exception is raised, and redoing the operation" can be encapsulated in a function. That function can then be used with any interruptible operation (such as putMVar, or atomically, or accept) *if* the operation guarantees that inside of a "block" it will either perform its operation, or interrupt and allow an asynchronous to be raised, but not both. _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
