This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Numbe
/--- On Fri, Sep 08, 2000 at 06:59:24AM +, Nick Ing-Simmons
wrote:
|
| >>> eval {
| >>> my($_a, $_b, $_c) = ($a, $b, $c);
| >>> ...
| lock $abc_guard;
| >>> ($a, $b, $c) = ($_a, $_b, $_c);
| >>> }
|
| Th
Bart Lateur <[EMAIL PROTECTED]> writes:
>On Wed, 06 Sep 2000 11:23:37 -0400, Dan Sugalski wrote:
>
>>>Here's some high-level emulation of what it should do.
>>>
>>> eval {
>>> my($_a, $_b, $c) = ($a, $b, $c);
>>> ...
>>> ($a, $b, $c) = ($_a,
On Wed, 06 Sep 2000 11:23:37 -0400, Dan Sugalski wrote:
>>Here's some high-level emulation of what it should do.
>>
>> eval {
>> my($_a, $_b, $c) = ($a, $b, $c);
>> ...
>> ($a, $b, $c) = ($_a, $_b, $_c);
>> }
>
>Nope. That doesn't ge
Dlux <[EMAIL PROTECTED]> writes:
>| I've deemed to be "too complex".) (Also note that I'm not a
>| database
>| guru, so please bear with me, and don't ask me to write the code
>| :-)
>
>Implementing threads must be done in a very clever way. It may be
>put in a shared library (m
> Are you satisfied with this? I think this is a good compromise, and
> still powerful :-)
Me satisfied? Well, kind of. I see the need, I just disagree with
the proposed interface and extent. I will not comment on the subject
much more because I sense that soon we'll be hip deep in database
/--- On Wed, Sep 06, 2000 at 05:16:03PM -0500, Jarkko Hietaniemi
wrote:
| Okay, I have read it now. Now I'm going to make suggestions :-)
| (Note
| that so far I've been commenting only on the aspects of making
| things
| 'thread-safe', not on the RFC itself. 'Threadsafing' Perl i
> Please read the RFC and AFTER you can make suggestions. These _all_
> are mentioned in the rfc!
Okay, I have read it now. Now I'm going to make suggestions :-) (Note
that so far I've been commenting only on the aspects of making things
'thread-safe', not on the RFC itself. 'Threadsafing' P
/--- On Wed, Sep 06, 2000 at 11:23:37AM -0400, Dan Sugalski wrote:
| >Here's some high-level emulation of what it should do.
| >
| > eval {
| > my($_a, $_b, $c) = ($a, $b, $c);
| > ...
| > ($a, $b, $c) = ($_a, $_b, $_c);
| > }
|
| Nop
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> I don't think we can do this immediately. Can you come up with the right
>> API and/or hooks that are needed so that it might be retrofited?
JH> I think language magic helping to do the user level data locking is
JH> a dead-in-the-wa
At 06:49 PM 9/5/00 +0200, Bart Lateur wrote:
>On Tue, 05 Sep 2000 11:48:38 -0400, Dan Sugalski wrote:
>
> >>- two-phase commit handler, rollback coordinator (the above two is
> >> connected to this: very simple algorhythm!)
> >
> >Here's the killer. This is *not* simple. At all. Not even clo
On Tue, Sep 05, 2000 at 10:57:30PM -0400, Chaim Frenkel wrote:
> > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> >> Now, "all" that needs to be taken care of, is make sure that the final
> >> assignment from the localized and changed variables to their
> >> outer-scoped counterpar
/--- On Tue, Sep 05, 2000 at 10:57:30PM -0400, Chaim Frenkel wrote:
| > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
|
| >> Now, "all" that needs to be taken care of, is make sure that
| >> the final
| >> assignment from the localized and changed variables to their
| >> outer-sco
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> Now, "all" that needs to be taken care of, is make sure that the final
>> assignment from the localized and changed variables to their
>> outer-scoped counterparts happens in *one step*, i.e. no task switching
>> while this is going o
On Tue, 5 Sep 2000 10:48:45 +0200, dLux wrote:
>/--- On Mon, Sep 04, 2000 at 07:18:56PM -0500, Greg Rollins wrote:
>| Will perl monitor the commit and rollback actions of transactions?
>\---
>
>What exactly you mean?
And did you have to quote 500+ lines of the RFC just to add this one
sentence?
> >Doing this properly with data sources you completely control in a
> >multi-access situation (read: with threads) is *hard*.
>
> Is it?
>
> Here's some high-level emulation of what it should do.
>
> eval {
> my($_a, $_b, $c) = ($a, $b, $c);
> ...
>
On Tue, 05 Sep 2000 11:48:38 -0400, Dan Sugalski wrote:
>>- two-phase commit handler, rollback coordinator (the above two is
>> connected to this: very simple algorhythm!)
>
>Here's the killer. This is *not* simple. At all. Not even close.
>
>Doing this properly with data sources you comple
/--- On Tue, Sep 05, 2000 at 11:48:38AM -0400, Dan Sugalski wrote:
| >- two-phase commit handler, rollback coordinator (the above two
| > is
| > connected to this: very simple algorhythm!)
|
| Here's the killer. This is *not* simple. At all. Not even close.
|
| Doing this properly with data
At 01:42 AM 9/4/00 +0200, dLux wrote:
>What it needs in the core is pretty small btw:
I think you underestimate things here a tad...
>- a new keyword, which is similar to "local"
Okay, that's small.
>- some extension to the TIE interface (some new callbacks)
As is this.
>- some extension to
/--- On Mon, Sep 04, 2000 at 07:18:56PM -0500, Greg Rollins wrote:
| Will perl monitor the commit and rollback actions of transactions?
\---
What exactly you mean?
dLux
--
This message is READ-ONLY
Will perl monitor the commit and rollback actions of transactions?
- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, September 04, 2000 4:35 PM
Subject: RFC 130 (v5) Transaction
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 02 Sep 2000
Mailing List: [EMAIL PROTECTED]
Vers
| Transactions are obviously going to be expensive and complicated,
| which
| is why I suggested implementing them outside the core:
[...]
| That's not quite sufficient for full transactions either. We
| should also allow
| user code to replace the assignment op in the virtual machi
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Chaim Frenkel wrote:
>> You are now biting off quite a bit.
KF> What good is half a transaction? If transactions are to be useful,
KF> they should be fully supported -- including rolling back stuff some
KF> third party module did to its inter
Chaim Frenkel wrote:
> You are now biting off quite a bit.
What good is half a transaction? If transactions are to be useful,
they should be fully supported -- including rolling back stuff some
third party module did to its internal variables. (Maybe that's a
little extreme ;)
> I believe that t
You are now biting off quite a bit. This is the generic problem that
all database systems have to do to handle transactions.
I believe that this will increase the deadlock possibilities. Without
a transaction, it might have been possible to get in and out of a subroutine
without holding the lock
/--- On Tue, Aug 29, 2000 at 06:33:41PM -0400, John Porter wrote:
| $x = 0;
|
| sub side {
| $x = 1;
| }
|
| trans {
| local $x;
| side();
| print "x=$x\n"; # should print 1
| die;
| }
|
| print "x=$x\n"; # should print 0
|
| Personally, I'd rather see transaction-ena
(I didn't think to respond to this until I saw a later response from dlux.)
Ken Fox wrote:
>
> try transaction {
> ...
> }
>
> That's a really interesting extension to exceptions -- code that has
> no side-effects unless it finishes.
Well, maybe transaction-enabling variables could
/--- On Tue, Aug 29, 2000 at 04:18:57PM -0400, John Porter wrote:
| > I was thinking about this same problem while reading RFC 130. It
| > seems
| > like transactions and exceptions are closely related. Should we
| > combine
| > the two?
| > try transaction {
| > ...
| > }
How woul
Ken Fox wrote:
>
> I was thinking about this same problem while reading RFC 130. It seems
> like transactions and exceptions are closely related. Should we combine
> the two?
>
> try transaction {
> ...
> }
>
> That's a really interesting extension to exceptions -- code that has
> no s
Chaim Frenkel wrote:
> > "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
> SF> Or what about a variable attribute:
>
> SF> my $x : transactional
>
> SF> and making the effect completely lexical? Why would other scopes need to
> SF> see such variables?
>
> You haven't handled the multiple var
> "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
SF> Or what about a variable attribute:
SF> my $x : transactional
SF> and making the effect completely lexical? Why would other scopes need to
SF> see such variables?
You haven't handled the multiple variable variety. You will need to
able t
Steve Fink wrote:
>
> "cond" for conditional?
I was thinking along that line, too. But coopting "conditional" in any way
is probably an ungood idea.
Probly "trans" is good; it has multiple useful mnemonic values: transactional,
transfer, transparent...
--
John Porter
We're building
At 12:19 PM 8/28/00 -0500, Jarkko Hietaniemi wrote:
> > Or what about a variable attribute:
> >
> > my $x : transactional
> >
> > and making the effect completely lexical? Why would other scopes need to
> > see such variables?
>
>Hear, hear! We do not want zillion and a half new keywords now that
> Or what about a variable attribute:
>
> my $x : transactional
>
> and making the effect completely lexical? Why would other scopes need to
> see such variables?
Hear, hear! We do not want zillion and a half new keywords now that
we have attributes.
--
$jhi++; # http://www.iki.fi/jhi/
dLux wrote:
>
> /--- On Thu, Aug 24, 2000 at 12:30:25PM -0400, John Porter wrote:
> | > Still not good. "trans" is too overloaded word. "transaction"?
> | > "transactional"? (a bit too long...) "atomic"?
> |
> | "acid"?
> \---
>
> "transactional" and "transaction" are quite long, I don't like th
/--- On Thu, Aug 24, 2000 at 12:30:25PM -0400, John Porter wrote:
| > Still not good. "trans" is too overloaded word. "transaction"?
| > "transactional"? (a bit too long...) "atomic"?
|
| "acid"?
\---
"transactional" and "transaction" are quite long, I don't like that.
"acid" could be mislead
Jarkko Hietaniemi wrote:
>
> Still not good. "trans" is too overloaded word. "transaction"?
> "transactional"? (a bit too long...) "atomic"?
"acid"?
http://www.cs.duke.edu/education/courses/cps212/fall98/slides-html/recover/tsld002.htm
http://www.byte.com/art/9504/sec11/art3.htm#fouracid
T
> =item *
>
> "safe" renamed to "trans"
Still not good. "trans" is too overloaded word. "transaction"?
"transactional"? (a bit too long...) "atomic"?
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 24 Aug 2000
Version: 4
Mailing List: [EMAIL PRO
dLux wrote:
>
>
> Thanks guys, you convinced me this is not a dead thing.
>
> I got some suggestion (2 phase commit support, DBI integration,
> other data source integration) from Glenn Linderman. I will improve
> this RFC with those things.
I might have mentioned this before, but I t
/--- On Wed, Aug 23, 2000 at 03:49:02PM -0400, David Corbin wrote:
| I think it would be a good thing, and would be another things can
| distinguish Perl from the other languages like pattern matching
| once
| did. It strikes me as one of those things that are going to end up
| adding a whol
dLux wrote:
>
> Hello!
>
> I've posted an RFC about transaction-enabled variables (RFC130:
> http://dev.perl.org/rfc/130.pod), but I didn't get too much response
> about that. Does anyone have comment about that? I want to clarify
> the language p
dLux wrote:
>
> I've posted an RFC about transaction-enabled variables (RFC130:
> http://dev.perl.org/rfc/130.pod), but I didn't get too much response
I think the RFC looks fine. This would be nice thing for perl to have.
--
John Porter
From: "dLux" <[EMAIL PROTECTED]>
Sent: Wednesday, August 23, 2000 7:32 AM
Subject: transaction-enabled variables
> I've posted an RFC about transaction-enabled variables (RFC130:
> http://dev.perl.org/rfc/130.pod), but I didn't get too much response
Hello!
I've posted an RFC about transaction-enabled variables (RFC130:
http://dev.perl.org/rfc/130.pod), but I didn't get too much response
about that. Does anyone have comment about that? I want to clarify
the language part of that (new keyword, new pragma), and if i
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 19 Aug 2000
Version: 3
Mailing List: [EMAIL PRO
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 18 Aug 2000
Version: 2
Mailing List: [EMAIL PRO
/--- On Fri, Aug 18, 2000 at 06:19:43PM -0400, Chaim Frenkel wrote:
| I don't think you should even attempt to version/transaction
| protect
| a tied variable. Anything that leaves the memory or could leave
| the
| memory (e.g. socket write) should probably not be versioned.
|
| Unles
I don't think you should even attempt to version/transaction protect
a tied variable. Anything that leaves the memory or could leave the
memory (e.g. socket write) should probably not be versioned.
Unless the tied variable somehow is able to tie itself into the
transaction manager. It is up for
/--- On Thu, Aug 17, 2000 at 06:17:51PM -0400, Chaim Frenkel wrote:
| Though this is a tough problem especially in the face of threads.
| Though versioned variables may be able to remove most of the
| locking
| issues and move it down into the commit phase.
Yes, but you can give strange
Think about deadlock, extra overhead, and time taken to take the lock.
If a set of variables should be locked as a unit only one mutex should
be assigned.
What to do about overlapping members
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> I wrote a transaction-enabled data
I wrote a transaction-enabled database in perl 5, using fork()
for my multithreading and flock() for my mutexes. It continues
to work just fine.
Threading gives us mutexes. Are you just saying that
every variable should have its own mutex, and perl's = assignment
operator should implicitly se
commit phase.
(But as always work is conserved. Somebody has to do the dirty work.)
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> =head1 TITLE
PRL> Transaction-enabled variables for Perl6
PRL> =head1 ABSTRACT
PRL> Transactions a
> We need to get a new keyword for defining such a variable, I think
> "transaction" is too long, we could use "safe" for this reason.
The proposal looks good. But isn't this more a language issue at this
point? Seems like we'll have to figure out the behavior we want first.
Also, "safe" i
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 130
=head1 AB
56 matches
Mail list logo
