emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.


From: Paul Eggert
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Tue, 22 Dec 2015 15:28:03 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

Eli Zaretskii wrote:

Is that practical?  One problem that I, as a module developer would
face, is to estimate the amount of stack I'd need for unwinding.
Where do I begin?

We could merely require that any module needing recursion must call a new stack-size-checking function at each level of recursion, in order to detect stack overflow.

Also, any module with an unbounded amount of computation should call the equivalent of QUIT every now and then. If the module API doesn't let (or ideally, require) modules to do that now, it should. Otherwise it's an Emacs freeze waiting to happen.

Then there are all the stack frames below the module, which belong to
some Lisp someone else wrote -- who will be responsible for ensuring
those other unwinders don't need large amounts of stack space that
might be unavailable at stack-overflow point?

Each stack-overflow unwinder should use only a small amount of stack space, in order to prevent an infinite loop. We could partially enforce this by detecting trivial infinite stack-overflow loops.

Stack overflow detection on modern systems uses hardware assistance
and processor exceptions to detect overflow with no runtime
penalties.  Doing the equivalent in application code is bound to incur
additional processing, which will slow down code, right?

Yes, but it's not a big deal.

If you think
about manipulating the guard pages to make them resizable, are we sure
enough of the supported platforms allow that?

In platforms that don't support guard pages we'll need to have the run-time checks. Either approach should be adequate.

Hitting stack overflow when some module runs is even rarer.
Why is it a disaster to fail to invoke the unwinders in those cases?

Often I expect it wouldn't be a disaster; it'd just be a memory leak. I suppose there could be some modules where it would be a disaster. But perhaps we can just ask people to not write such modules, by making it a part of the Emacs API that unwinders might not be invoked.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]