in reply to •Re^3: Is $^M a leftover April Fool?
in thread Is $^M a leftover April Fool?

I think you are correct, the problem is, what would cause my death handlers to be invoked?

What I mean is, if my program can never recieve notification of the impending disaster, how will it know to do clean-up?

From what I could workout, stealing 64k at the top of the program, just means that it runs out of memory 64k earlier than it would have. Then it makes use of the 64k reserve transparently, and then fails when the reserve runs out.

As I said in the original thread, the code is there and does seem to be activated, but from the perspective of my perl script, the result is (more or less) identical because it just fails with 'Out of memory' or a Dr.Watson pop-up, or a core dump depending upon how I have my system configured.

As far as I could work out, there is no way for my script to be notified that the reserve buffer is being used, so it has no way to do anything about it?

Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.

Replies are listed 'Best First'.
Re^5: Is $^M a leftover April Fool?
by rir (Vicar) on Jan 06, 2005 at 19:39 UTC
    If you are in &$SIG{__DIE__}() then your reserve buffer has been activated and this is the only memory space that you can count on.

    It's not that you know that you are out of memory. It is that you know you are dying, and if you have taken these precautions, you also know you have NNN bytes available for emergency actions.

    Be well,
    rir

[reply]
[d/l]

      Sorry if I am being dense, but I am still not getting this.

      So, if you happen, by some quirk of fate, to be in a die handler when, purchance, you should be low on memory, and your die handler requires some substantial amount of memory , then, if you have had the foresight to preallocate a reserve to $^M, then your handler will not fail to complete for a lack of memory.

      Does that cover it?

      Except that there is no way to trap an 'Out of memory' condition, so the likelyhood that you might happen to be in a die handler, just at the point where the memory demands of that die handler would push you over the limit of available memory are 1000:1?, 1000000:1?

      Useful.

      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.
[reply]
        Flip it around.
        1. You're in a death handler.
        2. You have no idea why you're there.
        3. Since it could be any reason, you have very little that you can count on.
        4. By using $^M, you have a certain amount of memory you can work with that you can count on. This is to make sure that your death handler will still work if you ran out of memory.
        5. It has no purpose otherwise. It doesn't provide any protection against other reasons you might be in a death handler.
        6. The chance it will be useful is OS and app dependent.

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
        I don't think you've got it.

        In C you could die because a memory request was denied by the OS. People would pre-allocate memory for the handler's needs. In Perl the same things could happen but since Perl is hiding your memory request from you, you can't be sure why you are dieing so it is wise to be prepared. In some OSes this situation is distinct from the OS being out of memory, Perl was written to such an OS.

        Be well,
        rir

[reply]
[d/l]

In Section Meditations