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 | [reply]
[d/l] |
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.
It certainly didn't start out that way. I originally came across $^M when I had a program that was occasionally dying through memory exhaustion. I went looking for a mechanism by which I could
- find out the circumstances that caused it.
- would allow me to take some action to prevent data loss by closing and flushing my open files etc.
- if possible, perform some action that would allow the process to recover and continue.
At the point where I posted the OP, had reached the conclusion that $^M could not be used for any of these purposes. No matter how many times I read what documentation there is, or searched the related source code, nor any of my various attempts a deviousness, nothing I did would allow me to use the only feature of perl that appeared to show (and still shows), some promise for tackling one or more of these goals.
So I made my original post in the hope that someone would explain what I was doing wrong or misunderstanding. That's where things stood until you recently re-opened the notion.
Since your post, I have re-covered some of the ground I went through originally before posting, and pretty much arrived at the same place.
Except that I now realise that whilst it is probably down to my stupidity that I misunderstood the purpose of $^M (though the documentation could be clearer in stating not just what it does, by why, and how a Perl programmer might make use of it), the actual use of it is somewhat (actually a lot) suspect.
Whilst, with some effort, it would be possible to engineer the circumstances under which the provision of a $^M memory reserve would be utilised, the chances of it ever actually occuring in the wild are somewhere between slim and none. And the benefits of its utilisation even slimmer.
Which is a shame, because given that the runtime will know when it is being called upon to make use of the reserve, the provision of a __MEM__ pseudo-signal could allow for the first 2 of the goals listed above to be realised. And under some circumstances, the last might also be achievable.
(I know, "Where's the patch!" :)
I'll shut up now!
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
| [reply] |