[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crash recovery strategies
From: |
Daniel Colascione |
Subject: |
Re: Crash recovery strategies |
Date: |
Sun, 3 Jan 2016 15:51:13 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
On 01/03/2016 03:47 PM, John Wiegley wrote:
>>>>>> Daniel Colascione <address@hidden> writes:
>
>> If implementing a scheme like this is what it takes to kill the stack
>> overflow code, I think I can implement it.
>
> Even if we don't kill the stack overflow code, would you be interested in
> trying out your async spawn idea? That might have other useful applications
> too. In fact, I've wanted to move async.el's ideas into the C level for a
> while (to avoid text-based marshalling between parent and child Emacsen), and
> this could dovetail beautifully with that desire...
How would moving to C help? Keep in mind that we're talking about fork
*and exec*, so the parent and child don't share memory. They can,
however, communicate over a pipe. Lisp already has read and print, so
given the choice, I'd rather implement cross-process functionality in
Lisp. Sure, that's text-based marshaling, but with it's general, isn't it?
They only difficulty I have in mind is making sure that the child Emacs
can display UI to the user, which involves matching window-system
parameters like DISPLAY.
That said, if we do end up implementing async-spawn, and we need to be
able to do it from C *anyway*, we can certainly expose that C
functionality to regular Lisp callers.
signature.asc
Description: OpenPGP digital signature
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., (continued)
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., John Wiegley, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Crash recovery strategies (was: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), John Wiegley, 2016/01/03
- Re: Crash recovery strategies, Daniel Colascione, 2016/01/03
- Re: Crash recovery strategies, John Wiegley, 2016/01/03
- Re: Crash recovery strategies, Daniel Colascione, 2016/01/03
- Re: Crash recovery strategies, John Wiegley, 2016/01/03
- Re: Crash recovery strategies, John Wiegley, 2016/01/03
- Re: Crash recovery strategies,
Daniel Colascione <=
- Re: Crash recovery strategies, John Wiegley, 2016/01/03
- Re: Crash recovery strategies, Eli Zaretskii, 2016/01/04
- Re: Crash recovery strategies, Daniel Colascione, 2016/01/04
- Re: Crash recovery strategies, Eli Zaretskii, 2016/01/04
- Re: Crash recovery strategies, Daniel Colascione, 2016/01/04
- Re: Crash recovery strategies, Eli Zaretskii, 2016/01/04
- Re: Crash recovery strategies, Paul Eggert, 2016/01/03
- Re: Crash recovery strategies, Daniel Colascione, 2016/01/03
- Re: Crash recovery strategies, John Wiegley, 2016/01/03
- Re: Crash recovery strategies, Paul Eggert, 2016/01/03