Eureka,
I claim to have written an implementation which agrees with all the semantics
that Simon Peyton-Jones wants for onCommit/onRetry/retryWith. See below:
Simon Peyton-Jones wrote:
| In many useful cases, such as the getLine example, the Y action will have
its
| own atomic {} block. In
| In many useful cases, such as the getLine example, the Y action will have its
| own atomic {} block. In which case the semantics of when it is allowed to
| re-attempt X are what is important. If you require (Y) to complete before
| re-attempting (X) then you get an infinite regression where
Hi,
After seeing how close I could come to creating onRetry/retryWith I have a
question about the semantics of your idea for retryWith.
Normally after a retry the STM block is rolled back and put to sleep and
will
only be awakened and re-executed if one of the STM variables it had read
Here I restate what you obviously know several times, then take a shot at
answering your final question.
Tim Harris (RESEARCH) wrote:
Hi,
After seeing how close I could come to creating onRetry/retryWith I have a
question about the semantics of your idea for retryWith.
Normally after a
| Normally after a retry the STM block is rolled back and put to sleep and will
| only be awakened and re-executed if one of the STM variables it had read from
is
| committed to by a different STM block.
The *semantics* are that it is retried anytime in the future. The *pragmatics*
are as you
| The basic idea is to provide a way for a transaction to call into
transaction-aware libraries. The libraries
| can register callbacks for if the transaction commits (to actually do any
O) and for if the transaction
| aborts (to re-buffer any I that the transaction has consumed). In
On Fri, Nov 24, 2006 at 08:22:36AM +, Simon Peyton-Jones wrote:
I have also toyed with adding
retryWith :: IO a - STM ()
The idea here is that the transction is undone (i.e. just like the 'retry'
combinator), then the specified action is performed, and then the transaction
On Fri, Nov 24, 2006 at 10:02:59AM +0100, Tomasz Zielonka wrote:
That's where retryWith would help. Right now I am using something named
autonomous transactions:
autonomously :: Bool - STM a - STM ()
This basically forks a new thread to perform the given transaction
outside of the
this thread reminds me about something that I wanted to ask you.
if I recall correctly, most of the literature references in STM papers
are recent, so I wondered whether you are aware of this one:
NAMING AND SYNCHRONIZATION IN A
DECENTRALIZED COMPUTER SYSTEM
SourceTechnical Report:
I posted an improved version of the new monad to the wiki at
http://haskell.org/haskellwiki/New_monads/MonadAdvSTM
Observations:
** This idiom made it easy for the retrying case to queue an action which
ensures success in the next attempt.
** More than one operation can be queued for both the
Simon Peyton-Jones wrote:
I have also toyed with adding
retryWith :: IO a - STM ()
The idea here is that the transction is undone (i.e. just like the 'retry'
combinator), then the specified action is performed, and then the transaction is
retried. Again no atomicity guarantee. If
,
Tim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Franksen
Sent: 24 November 2006 03:16
To: haskell@haskell.org
Cc: haskell-cafe@haskell.org
Subject: [Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
[sorry for quoting so
Hi,
On 23/11/06, Benjamin Franksen [EMAIL PROTECTED] wrote:
One answer is in fact to make it so that Console.Write can be rolled back
too. To achieve this one can factor the actual output to another task and
inside the transaction merely send the message to a transactional channel
(TChan):
13 matches
Mail list logo
