Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Thu, 24 Dec 2015 10:06:15 -0800
> 
> >> You'd prefer Emacs to lock up or corrupt data instead?
> > 
> > Instead of crashing and corrupting data?  What's the difference?
> > 
> > Of course, if it would do that all the time, or even most of the time,
> > we'd consider the solution a bad one, and remove it or look for ways
> > of improving it.  But we are not there; in most cases the recovery
> > doesn't hang and doesn't corrupt any data.
> 
> How would we know?

I was talking based on my own testing of the feature, back when I
implemented it for MS-Windows.

> In any case, I expect the undefined-behavior problem to be worse in a
> modules-heavy system, since most of the Emacs core code is written to
> use non-local control flow for error reporting already, and since it
> uses the GC for resource cleanup. I expect module code to be written in
> a style less tolerant of arbitrary non-local control flow.

Maybe you are right, it remains to be seen.  If indeed this is what
will happen, we will have to deal with that.

> I have seen no evidence that C stack overflow is a real problem that
> justifies the risks inherent in the current error handling scheme.

If it's not a real problem, then this entire discussion was moot,
since the code we are discussing will never run.

> In any case, the possibility of the C stack overflowing during GC isn't
> relevant to this discussion, since that has isn't covered by the current
> logic anyway.

Yes, but by artificially reducing available stack space, we might make
such irrecoverable problems more frequent.

> > It
> > sounds like just making the stack larger is a better and easier
> > solution.
> 
> I'd be perfectly happy deleting the stack overflow code entirely and
> increasing the declared stack size (on platforms where we ask for it).

If we think the current stack size is borderline, we could do that
regardless.  The lower the probability of stack overflow recovery to
be needed, the better.

> > Threads make this even more complicated.  At least on Windows, by
> > default each thread gets the same amount of memory reserved for its
> > stack as recorded by the linker in the program's header, i.e. 8MB in
> > our case.  So several threads can easily eat up a large portion of the
> > program's address space, and then the actual amount of stack is much
> > smaller than you might think.
> 
> We don't have to run Emacs on the main thread. We could, instead, with
> minimal code changes, call CreateThread on startup, supplying a larger
> stack size that applies only to that thread. Or we can let X=8MB and
> Y=2MB (the system default).

Yes, we could.  Assuming that Someone™ does the work of changing the
code that assumes that the main thread runs Lisp etc.

> I'm not clear on what you mean by "stack is smaller than you might
> think": on both POSIX systems and on Windows, thread stacks are address
> space reservations made at thread creation time.  If we can't fit another
> thread stack in the current address space, the failure mode is thread
> creation failing, not thread stacks being undersized.

I think lack of address space might mean the thread starts, but then
hits stack overflow, because the stack couldn't be expanded.

Also, at least on Windows the expression of this failure might be
non-obvious.  For example, we had a bug a couple of years ago where
the file selection dialog won't pop, or popped and then behaved
incorrectly, for this very reason.  Windows sometimes starts threads
on behalf of a process outside of our control.

> > So on balance, I don't see how your proposal is better.
> 
> I'm really not sure what's balancing the risk of data corruption and
> lockups caused by the stack overflow code. Emacs got along fine for
> decades before Dmitry added the stack overflow check late last year.

And I'm sure we will get along fine for many years hence.