From: Eli Zaretskii <eliz@gnu.org>
To: dmantipov@yandex.ru, eggert@cs.ucla.edu,
monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Proposal: block-based vector allocator
Date: Fri, 08 Jun 2012 12:41:24 +0300 [thread overview]
Message-ID: <83ehpquomz.fsf@gnu.org> (raw)
In-Reply-To: <83fwa6uqv5.fsf@gnu.org>
> Date: Fri, 08 Jun 2012 11:53:18 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>
> > Date: Fri, 08 Jun 2012 12:49:11 +0400
> > From: Dmitry Antipov <dmantipov@yandex.ru>
> > CC: emacs-devel@gnu.org
> >
> > Installed as 108520, with all suggested fixes and cleanups.
>
> This breaks the MS-Windows port: it infloops at startup. I will look
> into it and see what I find.
The immediate reason seems to be some mismatch of BLOCK_INPUT and
UNBLOCK_INPUT somewhere. The infloop is in
w32term.c:x_make_frame_visible, and it happens because
interrupt_input_blocked is non-zero after UNBLOCK_INPUT on line 5725
of w32term.c, which doesn't let the socket read hook run, and
therefore does not increment input_signal_count, which is a condition
for exiting this loop:
for (count = input_signal_count + 10;
input_signal_count < count && !FRAME_VISIBLE_P (f);)
{
/* Force processing of queued events. */
/* TODO: x_sync equivalent? */
/* Machines that do polling rather than SIGIO have been observed
to go into a busy-wait here. So we'll fake an alarm signal
to let the handler know that there's something to be read.
We used to raise a real alarm, but it seems that the handler
isn't always enabled here. This is probably a bug. */
if (input_polling_used ())
{
/* It could be confusing if a real alarm arrives while processing
the fake one. Turn it off and let the handler reset it. */
int old_poll_suppress_count = poll_suppress_count;
poll_suppress_count = 1;
poll_for_input_1 ();
poll_suppress_count = old_poll_suppress_count;
}
}
But the problem is not limited to this code alone. If I reset
interrupt_input_blocked to zero, the initial frame gets displayed
correctly, but Emacs then becomes unresponsive to input, presumably
again because BLOCK_INPUT mismatch somewhere.
Do we have some facilities to catch such mismatches? Any other ideas?
next prev parent reply other threads:[~2012-06-08 9:41 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-06 5:22 Proposal: block-based vector allocator Dmitry Antipov
2011-12-06 13:35 ` Stefan Monnier
2011-12-06 15:14 ` Dmitry Antipov
2011-12-06 19:39 ` Stefan Monnier
2011-12-07 5:05 ` Dmitry Antipov
2011-12-07 12:27 ` Carsten Mattner
2011-12-07 13:52 ` Stefan Monnier
2011-12-07 16:08 ` Dmitry Antipov
2011-12-07 16:30 ` Stefan Monnier
2011-12-08 8:50 ` Dmitry Antipov
2011-12-08 13:52 ` Stefan Monnier
2011-12-08 1:53 ` Stephen J. Turnbull
2011-12-08 4:41 ` Dmitry Antipov
2011-12-08 14:10 ` Stefan Monnier
2011-12-08 16:48 ` Dmitry Antipov
2011-12-08 19:58 ` Stefan Monnier
2011-12-09 7:32 ` Eli Zaretskii
2011-12-09 9:04 ` Dmitry Antipov
2011-12-09 14:05 ` Stefan Monnier
2011-12-09 16:15 ` Dmitry Antipov
2011-12-09 21:04 ` Stefan Monnier
2011-12-11 13:18 ` Dmitry Antipov
2011-12-12 3:07 ` Dmitry Antipov
2011-12-12 16:24 ` Stefan Monnier
2011-12-09 4:44 ` Stephen J. Turnbull
[not found] ` <jwvaa1yjs21.fsf-monnier+emacs@gnu.org>
2012-05-17 7:58 ` Dmitry Antipov
2012-05-18 17:40 ` Stefan Monnier
2012-05-21 12:19 ` Dmitry Antipov
2012-05-21 13:02 ` Andreas Schwab
2012-05-21 13:48 ` Dmitry Antipov
2012-05-21 15:07 ` Andreas Schwab
2012-05-22 5:23 ` Ken Raeburn
2012-05-21 20:12 ` Stefan Monnier
2012-05-22 8:24 ` Dmitry Antipov
2012-05-31 13:44 ` Dmitry Antipov
2012-05-31 15:43 ` Paul Eggert
2012-06-01 5:15 ` Dmitry Antipov
2012-06-01 5:44 ` Paul Eggert
2012-06-01 9:06 ` Dmitry Antipov
2012-06-01 17:36 ` Stefan Monnier
2012-06-02 0:32 ` Paul Eggert
2012-06-02 7:41 ` Eli Zaretskii
2012-06-03 6:49 ` Paul Eggert
2012-06-03 14:26 ` Eli Zaretskii
2012-05-31 21:16 ` Stefan Monnier
2012-06-01 7:34 ` Dmitry Antipov
2012-06-01 17:40 ` Stefan Monnier
2012-06-01 17:43 ` Stefan Monnier
2012-06-06 7:02 ` Dmitry Antipov
2012-06-06 13:13 ` Stefan Monnier
2012-06-06 14:58 ` Dmitry Antipov
2012-06-06 19:18 ` Stefan Monnier
2012-06-07 10:03 ` Dmitry Antipov
2012-06-07 14:07 ` Stefan Monnier
2012-06-08 5:50 ` Dmitry Antipov
2012-06-08 6:17 ` Stefan Monnier
2012-06-08 8:49 ` Dmitry Antipov
2012-06-08 8:53 ` Eli Zaretskii
2012-06-08 9:41 ` Eli Zaretskii [this message]
2012-06-08 10:00 ` Eli Zaretskii
2012-06-08 6:57 ` Eli Zaretskii
2012-06-08 6:38 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ehpquomz.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dmantipov@yandex.ru \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).