> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> I wasn't just talking about the threaded case though - the point
TH> which I was making was that of what happens if a single threaded
TH> program alters a hash in the middle of iterating it.
TH> Currently keys and values are flattened when
> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes:
UG> i don't see how you can do atomic ops easily. assuming interpreter
UG> threads as the model, an interpreter could run in the middle of another
UG> and corrupt it. most perl ops do too much work for any easy way to make
UG> them atomic with
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> Multithreaded programming is hard and for a given program the only
JH> person truly knowing how to keep the data consistent and threads not
JH> strangling each other is the programmer. Perl shouldn't try to be too
JH> helpful and ge
> what if i do $i++ and overflow into the float (or bigint) domain? that
> is enough work that you would need to have a lock around the ++. so then
> all ++ would have implied locks and their baggage. i say no atomic ops
> in perl.
>From RFC 178
[Atomic] operations typically lock their opera
> DS> Some things we can guarantee to be atomic.
> This is going to be tricky. A list of atomic guarentees by perl will be
> needed.
>From RFC 178
...we have to decide which operations are [atomic]. As a starting
point, we can take all the operators documented in C and
all the functions docume
> 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
In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> Why not
> lock(%y);
> foreach my $x (keys %y) {
> $y{$x+1} = 1;
> }
> unlock(%y);
>
> Hmm, I just realized, perhaps we can just punt. Any p5 program that
> doesn't use Threads
/--- 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:
JH> Multithreaded programming is hard and for a given program the only
JH> person truly knowing how to keep the data consistent and threads not
JH> strangling each other is the programmer. Perl shouldn't try to be too
JH> helpfu
> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Well, there'll be safe access to individual variables when perl needs to
DS> access them, but that's about it.
DS> Some things we can guarantee to be atomic. The auto increme
> But for a single 'statement', it may be possible to gather all the
> objects needing a lock and then grabbing them in order (say by address).
I still don't buy that. In Perl even simple assignments and
increments are not atomic which means that even 'single statements'
would require locking an
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> I guess we can translate all uses of keys and values when doing
TH> the p52p6 conversion - so that this:
TH> foreach my $x (keys %y)
TH> {
TH> $y{$x+1} = 1;
TH> }
TH> becomes:
TH> foreach my $x (@temp = keys %y)
TH> {
TH>
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Well, there'll be safe access to individual variables when perl needs to
DS> access them, but that's about it.
DS> Some things we can guarantee to be atomic. The auto increment/decrement
DS> operators can be reasonably guaranteed atomi
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> The snag with attempting to automate such things is illustrated by :
NI> thread Athread B
NI> $a = $a + $b++; $b = $b + $a++;
NI> So we need to 'lock' both $a and $b both side
> "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
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We punt. If the programmer wants consistent data in a multithreaded
> program, he or she needs to lock the hash down. I'm all up for the
> iterators looking at the hash as it exists--if the programmer wants
> a snaps
At 10:53 PM 9/5/00 -0400, Chaim Frenkel wrote:
> > "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?
What, perl not make an
At 05:17 PM 9/5/00 -0400, Chaim Frenkel wrote:
> > "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
Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>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 mini
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "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
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
24 matches
Mail list logo
