At 12:54 PM 1/29/2001 -0800, Thomas Butler wrote:
>: Jeanna FOx wrote:
>: > It also looks like some features are impossible to turn off -- like the
>: > mandatory locking that jwz hates about Java. It's not safe to turn it
>: > off, but it's not really safe with it on either. Some people would rather
>: > loose the illusion of safety to get better performance.
>: >
>:
>:
>: Well, mandatory locking is something we should definetly NOT have in Perl6.
>: Most of perl's code today is not threaded, and I believe much of it will
>: continue to be this way. The pseudo-fork thread behaviour that is being
>: proposed also makes this ok. Even if you have threads, you have to say
>: explicitly if you want anythinig to be shared. And if you explicitly
>: share something, then you should care the locks by yourself.
>:
>: At least, that's my opinion.
>
>What would you say to a default behavior of locking - which may be
>explicity altered with the correct commands / arguments to fork() or
>Thread->new()? I kind of think it is nice not having to worry about
>locking semantics, but would like the ability to turn it all off f I want.
Unfortunately there's really no sort of user-mode locking that perl can
provide that's not fundamentally broken for a non-trivial number of cases.
The best we can really do is make sure we don't corrupt internal data
structures, and leave the rest for explicit programmer locking.
This is, unfortunately, pretty much the state of affairs with any
Algol-like general purpose language I can think of. Things are different
with languages that are more special purpose, or that have different
funsamental assumptions, but for perl you're sort of out of luck.
Been there. Done that. Have the scorched T-shirt. Unfortunately. :(
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
