<[EMAIL PROTECTED]> writes:
>>
>> Anyone surprised by the top few entries:
>
>Nope. It looks close to what I saw when I profiled perl 5.004 and 5.005
>running over innlog.pl and cleanfeed. The only difference is the method
>stuff, since neither of those were OO apps. The current Perl seems to
>sp
> "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes:
>> my $a;
>>
>> Perl simply ignores locking. Thread gets the value of the winner
>> in a race condition. Perl does _not_ crash and burn. Internal
>> structures, mallocs, and accesses are properly mutexed.
SWM> I don't understand this
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
At 08:18 PM 9/4/00 -0400, Chaim Frenkel wrote:
> > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
>
>PRL> =head2 Freezing state for keys and values efficiently
>
>PRL> I believe this problem can be solved by using the vtable for the
>PRL> hash to wrap any mutating functions with a co
At 10:57 PM 9/4/00 -0400, Chaim Frenkel wrote:
> > "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes:
>PRL> All threads share the same global variables
> >>
> >> _All_ or only as requested by the user (ala :shared)?
>
>SWM> All.
>
>Dan has gone through this with perl5 and he really would
/--- 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 comple
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> This could be a lot more efficient than modifying the vtbl and filling
>> up the stack with the keys. I really am suspicious of replacing the
>> vtbl entry, there may be more than one thread working its way through
>> the hash.
DS> Or hav
All -
I fail to see the reason for imposing that all
variables
"know" how to perform ops upon themselves. An operation is
separate from the data it operates on. Therefore, I propose
the following vtbl scheme, with two goals:
1. that the minimal vtbl be just that, minimal
2. that it be pos
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Or have a "next" vtable function that takes a token and returns the next
> entry in the variable. Each iterator keeps its own "current token" and the
> variable's just responsible for figuring out what should get r
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I'd definitely rather perl not do any sort of explicit user-level locking.
DS> That's not our job, and there be dragons.
Please explain how this is possible?
Does this mean that without user specifying a lock, perl will allow
a chaotic
> "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
> "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes:
BS> variables
BS> "know" how to perform ops upon themselves. An operation is
BS> separate from the data it operates on. Therefore, I propose
BS> the following vtbl scheme, with two goals:
The point is to avoid the switches. There is no ne
> DS> I'd definitely rather perl not do any sort of explicit user-level locking.
> DS> That's not our job, and there be dragons.
> Please explain how this is possible?
Just say no...to locks.
> Does this mean that without user specifying a lock, perl will allow
> a chaotic update pattern to b
/--- 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
> >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, 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?
> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
GL> Chaim Frenkel wrote:
>> ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4)
>>
>> Actually, looking at it like that makes it an ugly situation. The 'new'
>> expectation would be to have it become
>> # $foo=1 $baz=2 @bar=(4)
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-enabled variables for Perl6
>
/--- 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
20 matches
Mail list logo
