[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Interferences between xwidgets and async processes?
From: |
Lars Ingebrigtsen |
Subject: |
Re: [PATCH] Interferences between xwidgets and async processes? |
Date: |
Sat, 14 Nov 2020 16:43:39 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Akira Kyle <ak@akirakyle.com> writes:
> However since glib 2e471acf breaks all this since glib now may install
> its signal handler multiple times instead of just once and will reset
> the signal handler to SIG_DFL if it doesn't have any watchers on that
> signal.
Oh, what a mess.
> I'm somewhat surprised this hasn't caused other issues so far,
> but I guess Emacs doesn't use glib for any process handling and own
> its own gtk isn't spawning any of its own processes on behalf of
> Emacs.
Yeah, the xwidget code is the only one I can recall doing this stuff.
Anybody?
> The attached patch fixes this but only in a temporary way.
Thanks; applied to Emacs 28. (I counted non-comment lines, and we're
still just below the number of lines before we need an FSF copyright
assignment. I forget whether I've asked this before -- would you be
willing to sign such paperwork, so that future patches can be applied?)
> I think that this should ultimately be fixed in glib by making it be a
> better signal handling citizen and do what Emacs does by saving any
> existing signal handler and call it from its own signal handler. I
> suppose I might be able to send them a patch if that seems like the
> best course of action here.
>
> [1] https://gitlab.gnome.org/GNOME/glib/-/issues/733
Yes, I think having a fix on the glib side sounds like the only
workeable long-term solution.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Re: [PATCH] Interferences between xwidgets and async processes?, JIANG Shaojian, 2020/11/09