(tye)Re2: Tied %SIG

When you tie a hash, attempts to change the hash no longer change the hash, they call a STORE method instead. So I have no reason to believe that your current method should manage to change the underlying, magical %SIG since it all boils down to $SIG{sig}= $codeRef generating a call to STORE that simply returns, doing nothing. In the case of $SIG{ALRM}, you call this STORE method twice, generating the second call to it from within the first call.

I suspect you have a found a bug in tied variables such that changes to the underlying tied hash leak through when you trigger a second STORE this way (or something similar). This bug probably has other, less desireable effects (like a recent bug where you can't use a different tied variable inside of a STORE method) and so may be fixed and the fix may break your ugly hack.

If you want to be able to change the original %SIG (in order to invoke the magic), then I really think you need to take steps such that you aren't tieing the original %SIG as changing a hash after it is tied isn't supported. You are relying on undocumented behavior.

What I suggested relies on documented behaviors. But it is fringe enough that I don't expect the standard test suites and beta testing would always turn up bugs that happen to break the combined behavior.

- tye (but my friends call me "Tye")

Comment on (tye)Re2: Tied %SIG Select or Download Code

Replies are listed 'Best First'.
(bbfu) Re: (tye)Re2: Tied %SIG by bbfu (Curate) on May 01, 2001 at 01:50 UTC
Ah, yes. Well, part of the problem I was having in the first place is that if I don't re-set `$SIG{ALRM}` it is still set to what the user set it to. Er, that is, this is what I mean is, even though my STORE method is getting called when `$SIG{ALRM}` is set to `\&foo`, `$SIG{ALRM}` is still being set to `\&foo`. I realize this is undocumented (I just forgot when I asked that last question :-p ). I'm going to try out switching out `%SIG`'s symbol table entry. I'll probably end up scrapping the whole thing. Blah. It's probably not that useful anyway. Thanks for your help. :-) bbfu Seasons don't fear The Reaper. Nor do the wind, the sun, and the rain. We can be like they are.	[reply] [d/l] [select]
(tye)Re3: Tied %SIG by tye (Sage) on May 01, 2001 at 01:58 UTC
Don't forget that after your change, people still need to be able to change `$SIG{INT}` (etc.) so your code needs to handle that. - tye (but my friends call me "Tye")	[reply] [d/l]
(bbfu) (the pain!) Re: (tye)Re3: Tied %SIG by bbfu (Curate) on May 01, 2001 at 02:06 UTC
Well, switching out `%SIG`'s symbol table entry totally kills all ability to set signal handlers. sigh Plus the STORE method doesn't even get called any more. Update: Oh wait, I lied. I was just doing it wrong. It does work, though it still seems dangerous. If I still go ahead with this, I'm definately making this at least a switch that defaults to off. :-) Well, it would have been cool if I could've gotten it to work. I still could but it would probably explode "at the most inconvient time" (says seanbo). I still think that they should fix it so we can tie `%SIG`... :-) Maybe I'll go ahead and write the rest of the code and just put in large disclaimers that it can't be used with legacy alarm code. Heh, maybe I could even put in a `$VOODOO` flag... ;-) Thanks again for all your help, tye. I had a pretty good idea when I started that I wouldn't be able to pull this off, and I'm suprised I got as far as I did. I certainly learned a thing or two in the process, which makes it all worth-while. bbfu Seasons don't fear The Reaper. Nor do the wind, the sun, and the rain. We can be like they are.	[reply] [d/l] [select]