/--- 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 is what
| 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 (mutex handling code, locking, etc.), but I
think there are more clevery guys out there who are more competent
in this, and I think it is covered with some other RFCs...
| If I understood correctly, you basically want to extend the
| existing
| tie()-interface to be useful for versioned variables. (That they
| are
| 'transactioned' is just a choice of words.) To *safely* do data
| versioning one needs database-like COMMIT and ROLLBACK features.
Basically yes.
| While I do understand your basic request and I quite like the idea
| of
| having versioned data, I do not see the need for a new variable
| type,
| neither by introducing a new keyword, nor a by a new variable
| attribute. Also, from implementation viewpoint introducing all the
| required thread-safeness into the very core of Perl doesn't sound
| good
| to me. Yes, it would be a very neat thing to have. But making all
| non-transaction-requiring Perl programs to pay the {speed,size}
| price
| for the thread-safing locking machinery doesn't sound good. Then
| again, having such functionality as an external "loadable module"
| doesn't sound too bad. What would be valuable from Perl 6
| RFC/design
| viewpoint would be to take a careful look at the tie() interface
| and
| for Perl 6 design an extendable interface so that methods like
| COMMIT,
| ROLLBACK, et cetera can be easily implemented.
I also don't like the overhead, that's why I made the "simple" mode
default (look at the "use transaction" pragma again...). This means
NO overhead, no locking between threads: this can be used in
single-thread or multi-process environment. Other modes CAN switch
on locking 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
