now.
I often visit use.perl, perl news, but I only got some rumours in
this list, no fact or official announcements.
Please smebody tell me what's going on nowadays!
Thanks, and keep up your _definitely good_ work :-)
dLux
--
o constructive suggestion in the last week. I fou want to
develop it, please use this RFC as the base of the discussion.
Thanks,
dLux
--
mailto:[EMAIL PROTECTED] icq:30329785
ocking functions, but this is not default! If you implement that
intelligently (separated .so for the thread handling), then it means
minimal overhead (some more callback call, and that's all).
Are you satisfied with this? I think this is a good compromise, and
still powerful :-)
\---
dLux
--
#!/bin/perl -sp0777i
thinks he can write the code that
implement this?
- is there any modification which makes it more powerful and make it
more simple?
dLux
--
Isten ovja a kepernyot! God save the screen!
lf of the variables are usable by
others, half ot that is not. Anyone can try to use that, and may
succeed. Next thread-switch to our thread will continue to release
the locks until all the locks are released.
I still think that we can implement this in a quite simple way IF we
assume we already designed our perl interpreter to thread-safe.
If you still have objections, share with us!
dLux
--
es running perl
| code.
If we do all you imagine, yes, but we only want to implement what is
to be implemented in the core, and this is not more than the 2pc
alg.
\---
dLux
--
This Message is Powered by VI
/--- 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
concurrency control (MVCC) like in postgreSQL
If we forget about the MVCC, then all things are very
straightforward, aren't they? It is _not_ complicated at all. It is
all Perlish!
\---
dLux
--
< Szabó, Balázs Tibor - dLux > - HuLUG - Allinphos
( m
;d rather see transaction-enabling requested on
| a per-variable basis.
I prefer that syntax too...
\---
Anyway, think "local" and "trans" as _different_, because these are
for _different_ purposes, and may the programmer get confused. For
example, he cannot use _re
ith objects, and tie interface. It needs some some
cleanings, because it is still not functional in this state (I need
some time to write a new version of the RFC), but I think this is
the future! Look at the Object interface and TIE interface in the
RFC.
Has anybody got ot
environment, and with objects).
Other suggestions? I want a keyword, which expresses more the nature
of the perl transaction: the value is permanent if the code runs
correctly, and will be lost if the code has died. What about
"onsuccess", "consistent", "? I personally prefer "trans", because
it is short and clean-cut.
Other idea?
dLux
--
This Message is Powered by VI
with those things.
dLux
--
([EMAIL PROTECTED], http://www.dlux.hu)
t is
clear, I want to take part in the detailed design of the
implementation.
dLux
--
"Don't THINK you are - KNOW you are"
(Morpheus, The Matrix)
e. Is it sounds sane?
Tied interface transaction-enable can be good, belive me!
dLux
--
... Végy egy Magnumot és fogd rá a Nyuszira!
strange results when using a versioned tied
variable.
That's why I thought versioning and more intelligent locking has
quite a lot overhead.
\---
dLux
--
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc
15 matches
Mail list logo
