#2401: unsafeIOToSTM discards exception handlers.
----------------------------+-----------------------------------------------
Reporter: sclv | Owner:
Type: bug | Status: closed
Priority: normal | Milestone: 6.10.1
Component: Runtime System | Version: 6.8.3
Severity: normal | Resolution: wontfix
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
----------------------------+-----------------------------------------------
Changes (by sclv):
* severity: major => normal
* summary: unsafeIOToSTM hangs with 64 bit multicore. => unsafeIOToSTM
discards exception handlers.
Comment:
(changing the ticket name to reflect the real issue)
I'm not happy with this for a number of reasons. Primarily because I
imagine the same effect could be achieved if, e.g., STM was operating on
an ostensibly pure data structure that hid an exception handler inside
via, e.g., unsafeInterleaveIO. I'll think more about when/how this could
come up using, e.g., only the standard libs, but I'm fairly sure I can
manufacture a case.
Second, I think unsafeIOToSTM should be as well supported as
unsafePerformIO in that one can break invariants with it if one is not
careful, but that it can be used "properly" to introduce new and useful
features. As it stands, unsafeIOToSTM with this issue is too unsafe to be
used even for debugging, much less for any real code.
Finally, because the semantics of STM as described in the papers don't run
into this problem, as the mechanism there only checks for consistency on
transaction commits, not at other arbitrary intervals as well (i.e. on
GC).
I tend to think that, although it obviously requires discussion, throwing
a real exception would make sense, especially since atomic rollback uses
the same stack unwinding mechanism in any case, as I understand it.
But, at a minimum, what would be nice is an RTS flag that disables the
consistency check on GC, and thus sidesteps this whole issue. Furthermore,
since there's a cost-benefit tradeoff to this check in any case, it would
be nice to let users tweak that setting and play with it.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2401#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
