[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: block-based vector allocator
From: |
Eli Zaretskii |
Subject: |
Re: Proposal: block-based vector allocator |
Date: |
Fri, 08 Jun 2012 12:41:24 +0300 |
> Date: Fri, 08 Jun 2012 11:53:18 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
>
> > Date: Fri, 08 Jun 2012 12:49:11 +0400
> > From: Dmitry Antipov <address@hidden>
> > CC: address@hidden
> >
> > 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?
- Re: Proposal: block-based vector allocator, (continued)
- Re: Proposal: block-based vector allocator, Dmitry Antipov, 2012/06/06
- Re: Proposal: block-based vector allocator, Stefan Monnier, 2012/06/06
- Re: Proposal: block-based vector allocator, Dmitry Antipov, 2012/06/06
- Re: Proposal: block-based vector allocator, Stefan Monnier, 2012/06/06
- Re: Proposal: block-based vector allocator, Dmitry Antipov, 2012/06/07
- Re: Proposal: block-based vector allocator, Stefan Monnier, 2012/06/07
- Re: Proposal: block-based vector allocator, Dmitry Antipov, 2012/06/08
- Re: Proposal: block-based vector allocator, Stefan Monnier, 2012/06/08
- Re: Proposal: block-based vector allocator, Dmitry Antipov, 2012/06/08
- Re: Proposal: block-based vector allocator, Eli Zaretskii, 2012/06/08
- Re: Proposal: block-based vector allocator,
Eli Zaretskii <=
- Re: Proposal: block-based vector allocator, Eli Zaretskii, 2012/06/08
- Re: Proposal: block-based vector allocator, Eli Zaretskii, 2012/06/08
- Re: Proposal: block-based vector allocator, Paul Eggert, 2012/06/08