Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Paul Eggert]

Daniel Colascione wrote:
> we should treat OOM exactly like other sorts of error.

Perhaps we should, but currently stack overflow is not treated that way.

> OS signals should go through the usual Emacs event loop, right?

I'm not sure what you mean, but let's put it this way: stack overflow can occur 
while in the low-level handler for an OS signal. And even if stack overflow does 
not occur, if the user types C-g three times when inhibit-quit is nil, the OS 
signal won't go through the Emacs event loop; instead, Emacs will invoke (signal 
'quit nil).

Perhaps what we need to do is to have stack overflow invoke (signal 
'stack-overflow nil), or something like that. It's a bit tricky, though, as one 
needs some stack space to call 'signal'.

> The standard requires runtimes reserve enough memory to throw
> std::bad_alloc. All Emacs has to do is make sure control flow reaches
> the C++ level.

How does this actually work, when combined with Emacs's C-level stack overflow 
checking? Won't one get in the way of the other?

> When we say that we want C++
> exceptions to work, the Emacs-relevant meaning is that Emacs should
> return always use conventional local returns, not longjmp, so that the
> stack unwinding facilities of other languages (e.g., C++) work properly.

Clearly we're not doing that, at least for stack overflow and 3x C-g, and 
perhaps for other cases (I haven't investigated thoroughly).

> Both the Python and Java extension APIs implement high-level exceptions
> with low-level state exactly the way we're talking about here, and the
> result has been generally usable.

I wonder how they deal with stack overflow, and/or with OS signals.