/--- 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
> >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
| 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 PROTECTED]
Numbe
35 matches
Mail list logo
