<div dir="ltr"><div>Hi Michael,</div><div><br></div><div>Good work - what a lovely topic for your master's thesis! There's something a little bit odd about the real world being able to access the result of a transaction that hasn't yet (and may still yet not be) committed, but your arguments for why this is a good thing are compelling. It is also a bit odd that a STM transaction nested running within the finalizer won't see the results of the previous transaction as it's not yet committed. Not too surprising once you read your justification, but surprising beforehand.</div><div><br></div><div>A finalizer which has non-atomic real-world effects needs to be quite careful about undoing those effects when exceptions are thrown. For instance, looking at your example code[1]:</div><div><br></div><font face="monospace, monospace">------------------------------------------------------------------------------<br><br>durably :: DatabaseHandle d -> TX d a -> IO a<br>durably h (TX m) = atomicallyWithIO action finalizer<br> where<br> action = runStateT m (database h, [])<br> finalizer (a, (_,ops)) = serialize ops h >> return a<br><br>serialize :: [Operation d] -> DatabaseHandle d -> IO ()<br>serialize ops (DatabaseHandle _ h) =<br> withMVar h (\h -> forM_ ops $ B.hPut h . runPut . safePut)<br><br>------------------------------------------------------------------------------</font><br><br>[1] <a href="https://github.com/mcschroeder/social-example/blob/8925056c/tx/TX.hs#L98">https://github.com/mcschroeder/social-example/blob/8925056c/tx/TX.hs#L98</a><br><div><br></div><div>If some of those <font face="monospace, monospace">B.hPut</font> calls succeed but then one fails (e.g. the disk is full) then the transaction will be rolled back, but the on-disk state will be left partially written. You're in good company with this problem, by the way - I've known large, expensive, commercial database products fail horribly and irretrievably in exactly this fashion when encountering a full disk at the wrong moment!</div><div><br></div><div>Even if the finalizer did include exception handling to deal with this situation, what happens with asynchronous exceptions? Does the finalizer run with async exceptions masked? I think it needs to: if not, then it seems it could run past the point where cleanup could occur and then receive an exception: essentially the finalizer runs to completion and then the STM transaction rolls back. Async exceptions get a brief mention in your thesis but I can't see anything about this point there - apologies if I've missed it.</div><div><br></div><div>Cheers,</div><div><br></div><div>David</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 July 2015 at 12:11, Michael Schröder <span dir="ltr"><<a href="mailto:mc.schroeder@gmail.com" target="_blank">mc.schroeder@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi everyone,<br><br>I want to finally announce some work I did as part of my master's thesis [1]. It's an extension to GHC's STM implementation. The main idea is to introduce a new primitive function<br><br><font face="monospace, monospace"> atomicallyWithIO :: STM a -> (a -> IO b) -> IO b</font><br><br>Like the existing <font face="monospace, monospace">atomically</font> operation, <font face="monospace, monospace">atomicallyWithIO</font> performs an STM computation. Additionally, it takes a <b>finalizer</b>, which is an arbitrary I/O action that can depend on the result of the STM computation, and combines it with the transaction in such a way that:<br><ol><li>The finalizer is only performed if the STM transaction is guaranteed to commit.<br></li><li>The STM transaction only commits if the finalizer finishes without raising an exception.</li></ol><div><br></div><div><br></div>A motivation of why this is useful: <br><div><div><br></div><div>Say we want to save the results of some STM transaction, i.e. persist them to disk. Currently, this is not possible in a transactionally safe way. The naive approach would be to first atomically perform some STM computation and then independently serialise its result:<br></div><div><div><br></div><div><font face="monospace, monospace"> do </font></div><div><font face="monospace, monospace"> x <- atomically m</font></div><div><font face="monospace, monospace"> serialize x</font></div><div><br></div><div>There are two issues with this. First, another thread could perform a second transaction and serialise it before we have finished serialising ours, which could result in an inconsistent state between the memory of our program and what is stored on disk. Secondly, the function <font face="monospace, monospace">serialize</font> might not terminate at all; it could throw an exception or its thread could die. Again we would end up with an inconsistent state and possibly data loss.</div><div><br></div><div>We might try to simply move serialisation into the atomic block, but to do this we have to circumvent the types, which should already be a huge red flag:</div><div><br></div><div><font face="monospace, monospace"> atomically $ do</font></div><div><font face="monospace, monospace"> x <- m</font></div><div><font face="monospace, monospace"> unsafeIOToSTM (serialize x)</font></div><div><br></div><div>The problem here is of course that an STM transaction can retry many times, which will also result in <font face="monospace, monospace">serialize</font> being executed many times, which is probably not something we want. Furthermore, if the thread receives an asynchronous exception, the transaction will abort in an orderly fashion, while <font face="monospace, monospace">serialize</font>, with its irrevocable side effects, cannot be undone.</div><div><div><br></div><div><div>But with finalizers, the solution is easy:</div><div><br></div><div><font face="monospace, monospace"> atomicallyWithIO m serialize</font><br><br></div><div><br></div><div>I've written a small example application that uses finalizers and other stuff from my thesis to build a lightweight STM database framework: [2]</div><div><br></div><div>There are more possible uses cases besides serialisation (such as interactive transactions) and some interesting issues surrounding finalizers (like nesting of transactions) which are discussed in greater detail in my thesis [1], which also includes a formal operational semantics of the whole thing.<br></div><div><br></div><div>I have implemented finalizers in my fork of GHC [3], if any of you want to play around with them yourself. The atomicallyWithIO function is exported from the GHC.Conc.Sync module.</div><div><br></div><div><br></div><div>Cheers,</div><div>Michael</div><div><br><br>[1] <a href="https://github.com/mcschroeder/thesis" target="_blank">https://github.com/mcschroeder/thesis</a></div><div>[2] <a href="https://github.com/mcschroeder/social-example" target="_blank">https://github.com/mcschroeder/social-example</a></div><div>[3] <a href="https://github.com/mcschroeder/ghc" target="_blank">https://github.com/mcschroeder/ghc</a><br><br></div></div></div></div></div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>