in reply to Tied %SIG

I can't guess why you think that your other methods should work. STORE methods do not set values by returning a value nor by overwriting the $key parameter.

Now, if you get anything to work, consider yourself lucky and worry about in what release of Perl it will break. %SIG is magical (yes, that is the real term for it). So when you set values of %SIG, C code inside of Perl gets run in order to set up actual signal handlers. What triggers this C code is called "magic" and you'll have to go read "perldoc perlguts" (and then some) if you want to know more about it.

If I were going to try this, I'd keep a reference to the original %SIG handy and then replace %SIG with my tied hash: 

my $realSig= \%::SIG;
*::SIG= {};
tie %::SIG, ...

[download]
which I have some hope would separate the magic from the tiedness. But I can't offer any guarantees.

(I don't know if the "::"s are of any use in the above code. The "SIG" is special to Perl such that it knows to always find it in package "main", but I'm not certain that this specialness would always be triggered in the above code so I'm trying not to rely upon it.)

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

Replies are listed 'Best First'.
(bbfu) Re: (tye)Re: Tied %SIG
by bbfu (Curate) on May 01, 2001 at 01:22 UTC

    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.

[reply]
[d/l]
[select]

      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]

In Section Seekers of Perl Wisdom