in reply to (tye)Re: Tied %SIG
in thread Tied %SIG

Yeah, I realized that the other methods probably wouldn't work (and wasn't suprised when they didn't) but I thought I'd try them anyway (and included them for completeness).

I don't want to run afoul of Perl Magic but I don't see how the method that does work (Ugly Hack) could break in the future. Unless, of course, they change it so that the STORE method is never called (ie, you cannot tie %SIG, period). Can you see any reason why it would?

Personally, it would seem to me that trying to replace %SIG's symbol-table entry would be more likely to break Perl than my method. Thoughts?

In summary, can you see any reason why I shouldn't go ahead with the method that currently works?

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.

Replies are listed 'Best First'.
(tye)Re2: Tied %SIG
by tye (Sage) on May 01, 2001 at 01:41 UTC

    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")
[reply]
[d/l]
[select]

      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]

        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]

In Section Seekers of Perl Wisdom