[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?

reply via email to

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