Front page | perl.perl5.porters |
Postings from October 1999
On Tue, 26 Oct 1999 10:54:51 +0200, "Matthias Urlichs" wrote:
>Tuomas J. Lukka:
>>
>> Actually, I think that maybe
>> $lock = lock $obj;
>> undef $lock;
>> would make a nice interface
>
>That's somewhat nonintuitive, IMHO, because the current semantics of
[..]
>so the lock code would need some internal magic to determine whether its
>return value is going to be stored anywhere.
>
>Somehow I doubt that the current Perl core allows for this..?
Look up "void context" some time.
The suggested change could be implemented easily, but I'm somewhat
concerned about the possibility for people inadvertantly hosing
themselves. In the above example, forgetting to undef the $lock
would mean the lock is alive for the entire life of the program.
It may be safer to always require "named locks" (as opposed to the
existing "anonymous locks") to be variables that have a limited,
well defined lifetime, such as a typed lexical. One can always
obtain additional references to lock variables to extend their
lifetime when needed.
sub try_lock {
my lock $foo = $_[0]; # same as: my $foo = lock($_[0])
return $foo if some_condition();
return undef;
# $foo unlocks naturally here
}
{
my $bar = try_lock($this); # extend hold on lock
do_stuff_while_locked() if $bar;
}
Sarathy
gsar@ActiveState.com
Thread Previous
|
Thread Next