At 04:21 PM 9/8/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> The problem with using database locking and transactions as your
>DS> model is that they're *expensive*. Amazingly so. The expense is
>DS> certainly worth it for what you get, and in many
Chaim Frenkel wrote:
> No scanning. I was considering that all variables on a store would
> safe store the previous value in a thread specific holding area[*]. Then
> upon a deadlock/rollback, the changed values would be restored.
>
> (This restoration should be valid, since the change could not
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The problem with using database locking and transactions as your
DS> model is that they're *expensive*. Amazingly so. The expense is
DS> certainly worth it for what you get, and in many cases the expense
DS> is hidden (at least to some ex
> "r" == raptor <[EMAIL PROTECTED]> writes:
r> ]- what if we don't use "locks", but multple versions of the same variable
r> !!! What I have in mind :
r> If there is transaction-based variables THEN we can use multiversioning
r> mechanism like some DB - Interbase for example.
r> Check here
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> Please consider carefully the potential consequences of your proposal.
I just realized, that no one has submitted a language level proposal how
deadlocks are detected, delivered to the perl program, how they are
to be recovered from, Wh
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> Chaim Frenkel wrote:
>> What tied scalar? All you can contain in an aggregate is a reference
>> to a tied scalar. The bucket in the aggregate is a regular bucket. No?
AB> So you don't intend being able to roll back anything that has bee
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> Chaim Frenkel wrote:
>> You aren't being clear here.
>>
>> fetch($a) fetch($a)
>> fetch($b) ...
>> add ...
>> store($a) store($a)
>>
>> Now all of the perl internals are don
At 06:18 PM 9/7/00 -0400, Chaim Frenkel wrote:
> > "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>
>AB> Chaim Frenkel wrote:
> >> The problem I have with this plan, is reconciling the fact that a
> >> database update does all of this and more. And how to do it is a known
> >> problem, its
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> Chaim Frenkel <[EMAIL PROTECTED]> writes:
NI> Well if you want to place that restriction on perl6 so be it but in perl5
NI> I can say
NI> tie $a[4],'Something';
That I didn't realize.
NI> Indeed that is exactly how tied arrays wo
Dan Sugalski wrote:
> At 05:30 PM 8/31/00 -0400, Ken Fox wrote:
> > before_get_value
> > after_get_value
> > before_set_value
> > after_set_value
> >
> >There ought to be specializations of get_value and set_value
> >that call these hooks if they're defined -- no sense in making the
> >nor
> Example
>
> @a = ();
> async { push @a, (1, 2, 3) };
> push @a, (4, 5, 6);
> print @a;
>
> Possible output: 142536
Actually, I'm not sure I understand this.
Can someone show how to program push() on a stack machine?
- SWM
> > You aren't being clear here.
> >
> > fetch($a) fetch($a)
> > fetch($b) ...
> > add ...
> > store($a) store($a)
> >
> > Now all of the perl internals are done 'safely' but the result is garbage.
> >
> I don't even want to take things out a step to guarantee atomicity at the
> statement level. There are speed issues there, since it means every
> statement will need to conditionally lock everything. (Since we can't
> necessarily know at compile time which variables are shared and which
> aren't
Chaim Frenkel wrote:
> You aren't being clear here.
>
> fetch($a) fetch($a)
> fetch($b) ...
> add ...
> store($a) store($a)
>
> Now all of the perl internals are done 'safely' but the result is garbage
Chaim Frenkel wrote:
> What tied scalar? All you can contain in an aggregate is a reference
> to a tied scalar. The bucket in the aggregate is a regular bucket. No?
So you don't intend being able to roll back anything that has been
modified via a reference then? And if you do intend to allow th
Jarkko Hietaniemi wrote:
> Being multithreaded is not difficult, impossible, or bad as such.
> It's the make-believe that we can make all data automagically both
> shared and safe that is folly. Data sharing (also known as code
> synchronization) should be explicit; explicitly controlled by the
I am reading various discussions regarding threads, shared objects,
transaction rollbacks, etc., and was wondering if anyone here had any
thoughts on instituting an event model for Perl6? I can see an event model
allowing for some interesting solutions to some of the problems that are
currently be
/--- 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
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>What tied scalar? All you can contain in an aggregate is a reference
>to a tied scalar. The bucket in the aggregate is a regular bucket. No?
I tied scalar is still a scalar and can be stored in a aggregate.
Well if you want to place that restriction o
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,
20 matches
Mail list logo
