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.

Okay, so the number of runs of a Perl program in which this feature comes into play approximates to:

Count *every* run, of *any* perl program, *anywhere*.

Divide by that number where $^M was set.

Divide by that number that a death handler was entered at some point.

Divide by that number that ran out of memory at that *at that point*.

Divide by that number that are running on an appropriate OS.

Divide by that number that constitute an application the might benefit.

If 10% had $^M set, and 10% of those enter a death handler at some point, and 10% of those coincidentally run out of memory, and 10% of those are running on an appropriate OS and 10% of those could benefit from their death handlers not running out of memory before dying,

I make that 0.001% of perl scripts that might benefit, which makes my million to 1 shot guess look prescient.

If, like me, you consider that 10% is at least an order of magnitude too high for at least 2 of those, and 2 orders of magnitude to high for a third, then you the figure is more like 0.0000001%, which makes the million to one shot look positively optimistic.

Anyone want to buy some alien abduction insurance? :)

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

How many scripts use the dbmopen function? You can point to at least half the features in Perl and realize that less than 1% of all scripts in existence directly use that code. In many cases, probably much less than that.

Granted, $^M is a very obscure and esoteric feature, but so is dbmopen ...

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.

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

Okay, let me see if I can turn my problem around.

1. Can you tell me what symptoms I should look for when I have a perl script that is routinely failing, that will tell me that I should consider setting $^M to some value?
2. How should I determine how big a reserve to allocate?
3. How would I determine that the provision of said reserve has been successful?

For bonus points, can you provide

• A demonstration of the feature in use?
• an estimate for the number of times this feature has resulted in the successful completion of a program, when it would have otherwise failed?
<

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Okay. I do have a feeling that you pose your questions to show this $^M stuff as a crufty corner of Perl instead of to learn about memory allocation issues. If that is the case; I agree with you: it's a crufty corner. If not perhaps these answers will help.

1. If your die handler doesn't function as you expect when you force a memory scarcity situation on your process.

2. Big enough to contain all the thingies you create in your die handler.

3. Watching memory usage of the process. Seeing your handler start working when it didn't in a memory scarcity situation.

As a demo your sample is about all there is to it. Set $^M to the space you may need. The rest is automagical, except figuring out what size to set it.

How often is this an issue? See #1 above; how often do people feel the need to do resource scarcity testing? How often do people recompile Perl to enable odd features? How often do people use signal handlers? Most people--never.

Your estimate question and somewhat similar statements in this thread make me feel you expect too much of this mechanism. You don't go into your die handler, then jump back to your program to live again. Instead you use the memory to die in an effective manner, you use it to say your last words.

Be well,
rir