bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw


From: Eli Zaretskii
Subject: bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw
Date: Tue, 31 Mar 2015 17:03:29 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jan.h.d@swipnet.se,  nicolas@petton.fr,  19175@debbugs.gnu.org,  
> mb@becroft.co.nz
> Date: Tue, 31 Mar 2015 09:26:58 -0400
> 
> >> How old is this bug?  IIUC it's pretty old, so there's no hurry to
> >> fix it in 24.5 rather than in Emacs-25.  It's not fixing a regression.
> > It is still a bad problem, and could very well raise its ugly head in
> > other, more important situations.
> 
> It could, but it hasn't in the last many years that we've lived with it
> without anyone noticing, so we can live with it a few more I think.
> And the effect of the bug seems rather minor.
> IOW the urgency is very low.

I don't see it as low: subtle, hard to reproduce failures in Xlib
calls could very well bring the whole session down.  That they only
happened when opening a new frame might very well be sheer luck.

IME, the fact that a bug never happened (or, more accurately, was
never reported) before says nothing at all about its probability or
the chance to see it again tomorrow.  These are Poisson processes, and
they are known to be nasty in this regard.

> >> > Fixing the ChangeLog is easy, if
> >> > that's the only problem: just swap the entries.
> >> No, the problem is delaying the release by having another RC candidate.
> > There's no need: we are making a simple change that doesn't require
> > another RC, IMO.
> 
> I don't find it simple at all.  E.g. it doesn't seem obviously safe
> (e.g. what if the X call ends up making a longjmp and hence skipping the
> unblocking of sigio?

If we fear this, it should be a simple manner to see if Xlib does any
longjmp at all.

> Low urgency, non-zero risk, I'm surprised you'd even bother to lobby for
> inclusion one day before the actual release.

That's because I disagree about both the urgency and the risk.  Also,
should it prove to be a problem, immediately releasing 24.6 with that
change reverted is a very simple matter.

So I see no reason not to include this patch in 24.5.  We have nothing
to lose, really.





reply via email to

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