Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> >perlfunc is wrong by the way. At least for 5.8.0 -- or should "lock()" be a
> >keyword when threads.pm is loaded ?
>
> I am begining to grasp what is going on. But I don't know the answer
> to the question. I suspect that the answer is "no" - the glimmer in my
> brain is that it was a keyword for Thread.pm because back then we did
> not have the equivalent of \[$@%] as a prototype, and so a keyword
> was only way to allow "anything" as an arg.
>
> The answer is also probably "no" because "lock" is in threads::shared.
What do you mean ? lock is not in threads::shared, it's in the core.
Unless a subroutine lock() is defined in the current scope, it's compiled
to OP_LOCK. pp_lock() is mainly a wrapper around SvLOCK, which in turn
calls Perl_sharedsv_locksv() when threads::shared has been loaded (via
the global function pointer PL_lockhook). This enables to define several
implementations for the lock() built-in, depending on PL_lockhook.
And BTW I don't like the concept of a weak keyword that becomes a normal
keyword when a module is loaded. The usual way to change the parsing
behavior is to use a pragma, because it's lexically scoped.
Currently using Thread.pm changes the parsing of lock() even in modules
used by your modules. That's why I think lock() should always be a weak
keyword -- and moreover that's backward-compatible. Or introduce a new
hint ($^H{LOCK_KEYWORD_ISNT_WEAK} -- yes I know, hints must be fixed,
as Cato used to say.)
Another possibility is to get rid of PL_lockhook and move Perl_sharedsv_locksv()
into the core (after 5005threads are removed.)
Arthur ? sounds like a good idea ?
