Thanks Tim that with the readers and writers is what I figured. On Oct 16, 12:12 am, Timothy Baldridge <[email protected]> wrote: > I can't answer most of these, but I'll take a crack at a) > > From my understanding of the clojure code, the answer to long running > transactions will depend on your application. If you have one writer, > and 100 readers, you'll be fine. The readers will read the old value > while the writer is updating the ref to the new value. You will run > into problems if you have 100 writers and 1 reader, however. Your > program won't hang or deadlock, but you may have the case where the > same 1 minute chunk of code is recalculated several times. Having a > transaction re-run may not be a big issue if the transaction's values > take 1ms to calculate, but 1 minute would probably be a bit more of an > issue. > > Timothy > > > > > a) can STM transactions contain calculations that take a 'long' time, > > let's say computing the cryptographic hash of a plaintext. I'd > > 'ensure' the input parameters such as plain text, hash algo and bit- > > length, compute the hash (can be slow) and store the hash in a ref. > > What I'd need here is that the calculation is interrupted if the > > transaction is aborted for a retry. No need to complete the long > > calculation if we aren't going to store the result anyway. The > > existing convention in Java is to set the interrupt flag on a thread > > which is queried ever now and then by long-running calculations. This > > is a convention that many Java libraries adhere to. So how to do this > > interrupting?
-- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
