> The Haskell runtime keeps track of how much memory each Haskell thread has allocated in total, and if that total exceeds the limit we set, the thread receives an asynchronous exception, namely AllocationLimitExceeded. The user code running on our platform is not permitted to catch this exception, instead the server catches it, logs some data to aid debugging, and sends an error back to the client that initiated the request.<p>This is actually pretty cool. This way the server stays in charge of the threads it spawns, rather than having to build in some auto-destruct feature into the thread itself (which may not necessarily fire). The thread becomes more like a sandboxed environment -- with resource quotas -- than an independent entity, which I think is what we want, if we want to be able to reason about our code.
"You can throw an exception to another thread, at any time;"
"The other thread will receive the exception immediately, whatever it is doing."<p>Does anybody know how this is implemented in the runtime system?
How does one thread communicate with another thread?
And how do you need to look at this for it <i>not</i> to be a side-effect?<p>Any insight is much appreciated.
A common pattern is trying to recorver from IO exceptions but treating asynchronous exceptions as fatal. The safe-exceptions package helps with that: <a href="http://hackage.haskell.org/package/safe-exceptions" rel="nofollow">http://hackage.haskell.org/package/safe-exceptions</a>
>"When we originally added asynchronous exceptions to Haskell ... was shortly after Java had removed the equivalent feature, because it was impossible to program with."<p>>"...if [Haskell wants] to be able to interrupt ... asynchronous exceptions are the only way, because polling would be a side-effect"<p>File under "Indictments against Haskell". We're gonna need a bigger filing cabinet.