Dean Arnold wrote: > any chance of threads::shared chaining the lockhook > and destroyhook (ie, saving the current funcptr before > assigning to it, then checking the SV is shared > when its hook functions get called, and forwarding on > if the SV isn't shared ? (I've been meaning to put together > a patch for this). It may not be needed > if CORE always sets up threads::shared 1st, but just > in case some other module wants to hook in, and we don't > know the hooking order beforehand, it might be useful. > (Note this doesn't require CORE changes, just threads::shared > changes)
In core Perl, PL_lockhook and PL_destroyhook are both set to stubs that essentially do nothing. With PL_lockhook, calling lock($var) does nothing if threads::shared is not loaded. If threads::shared is loaded, then lock($var) on a non-shared variable croaks. With the chaining you're suggesting, and with nothing else in the chain, the later would change (i.e., it reverts to the former case). If another module wants to chain, then ordering might become an issue. Is there another PL_ hook variable that does chaining that I could investigate as an example of how it all might work?
