At 1:50 PM -0700 6/1/06, Larry Wall wrote:
As for side-effecty ops, many of them can just be a promise to perform
the op later when the transaction is committed, I suspect.
Yes, but it would be important to specify that by the time control is
returned to whatever invoked the op, that any side
"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote:
On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote:
Forgive this ignorant soul; but what is "STM"?
Software Transaction Memory
Well, Software Transactional Memory if I'm being picky. :-) Some info and
an interesting paper here:-
On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote:
> Larry Wall wrote:
> >The way I see it, the fundamental difference is that with ordinary
> >locking, you're locking in real time, whereas with STM you potentially
> >have the ability to virtualize time to see if there's a way to order
Larry Wall wrote:
The way I see it, the fundamental difference is that with ordinary
locking, you're locking in real time, whereas with STM you potentially
have the ability to virtualize time to see if there's a way to order
the locks in virtual time such that they still make sense. Then you
jus
On Thu, Jun 01, 2006 at 11:52:59AM +1200, Sam Vilain wrote:
: The lock on entry approach will only be for non-threaded interpreters
: that don't know how to do real STM.
The way I see it, the fundamental difference is that with ordinary
locking, you're locking in real time, whereas with STM you po
Darren Duncan schreef:
> Each time a context (a code block, either a routine or a syntactic
> construct like 'try' is) is entered that is marked 'is atomic', a new
> transaction begins, which as a whole can later be committed or rolled
> back; it implicitly commits if that context is exited normal
At 11:51 AM +1200 6/1/06, Sam Vilain wrote:
I think the answer lies in the "checkpointing" references in that
document. I don't know whether that's akin to a SQL savepoint (ie, a
point mid-transaction that can be rolled back to, without committing the
entire transaction) or more like a continuat
Daniel Hulme wrote:
>>How does an atomic block differ from one in which all variables are
>>implicitly hypotheticalized?
>>
>>
>I assume that the atomicness being controlled by some kind of lock on
>entry, it also applies to I/O and other side-effecty things that you
>can't undo.
>
The lock o
Jonathan Lang wrote:
>How does an atomic block differ from one in which all variables are
>implicitly hypotheticalized? I'm thinking that a "retry" exit
>statement may be redundant; instead, why not just go with the existing
>mechanisms for successful vs. failed block termination, with the minor
> How does an atomic block differ from one in which all variables are
> implicitly hypotheticalized?
I assume that the atomicness being controlled by some kind of lock on
entry, it also applies to I/O and other side-effecty things that you
can't undo.
--
Hats are no worse for being made by ancien
How does an atomic block differ from one in which all variables are
implicitly hypotheticalized? I'm thinking that a "retry" exit
statement may be redundant; instead, why not just go with the existing
mechanisms for successful vs. failed block termination, with the minor
modification that when an
11 matches
Mail list logo
