Re^5: Is $^M a leftover April Fool?

[rir]

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

[BrowserUk]

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.

[dragonchild]

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.

[BrowserUk]

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? :)

[rir]

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

[BrowserUk]

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?
<