Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Mon, 4 Jan 2016 07:40:48 -0800
> 
> >> The quick and dirty fix for Fdo_auto_save is to run
> >> Fdo_auto_save in a forked child
> > 
> > Forking a child from a damaged parent is likely to leave us with the
> > same problem in the child.  Also, if the original session uses up a
> > lot of memory, the fork could simply fail.  (You later suggested a
> > vfork + exec, but that doesn't allow auto-saving from the child,
> > AFAIU.)
> 
> The idea is that we can wait a bounded amount of time for the child,
> then kill it if it misbehaves.

Yes, but then there's no auto-saving, so this trick seems pointless to
me.

> The reason I suggested vfork is that glibc (the quality of which
> continues to disappoint me) doesn't provide an async-signal-safe
> fork. With the scheme I proposed, we don't *need* an
> async-signal-safe fork, since we can perform the entire emergency
> save operation inside the signal handler, without invoking
> lisp. We'd just vfork and exec to ask the user what we want to do,
> which is an optional process.

Why do we need to vfork+exec just to ask a question?  We do this today
with a very low-level I/O calls, and that code worked since about
forever (I remember studying it 25 years ago).