[Top][All Lists]

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

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

From: Eli Zaretskii
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Mon, 04 Jan 2016 18:07:10 +0200

> 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

> 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).

reply via email to

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