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, $_b, $_c);
}
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 (mutex
/--- 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
"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-water idea.
/--- 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
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
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 the
/--- 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
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 completely
| 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
"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 internal
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
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 variable variety. You
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
/--- 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 would you
(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 help
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 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/
#
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
we have
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
"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 to have a
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 PROTECTED]
22 matches
Mail list logo
