On 2/21/2019 6:52 PM, Ken Brown wrote:
> When emacs is built, it detects the timerfd functions and uses them if they're
> found. Now that Cygwin has these functions, the resulting build of emacs is
> very slow to respond to user input. If I press a key, there is a 1-2 second
> delay before emacs responds.
>
> I can work around this by configuring emacs with emacs_cv_have_timerfd=no, but
> it would be nice to find the cause. I'll try to make an STC, but I thought
> I'd
> report it here in the meantime, in case anyone has ideas or debugging
> suggestions.
I don't have an STC yet, but if I start emacs and then attach gdb to it at
random times, the backtrace always look like this:
#0 0x00007ffbb192b4f4 in ntdll!ZwWaitForMultipleObjects ()
from /c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x00007ffbadf56099 in WaitForMultipleObjectsEx ()
from /c/WINDOWS/System32/KERNELBASE.dll''
#2 0x00007ffbadf55f8e in WaitForMultipleObjects ()
from /c/WINDOWS/System32/KERNELBASE.dll
#3 0x0000000180159f9d in timerfd_tracker::wait (this=this@entry=0x1803a22c0,
nonblocking=false)
at /usr/src/debug/cygwin-3.0.1-1/winsup/cygwin/timerfd.cc:448
#4 0x00000001800a7b0e in fhandler_timerfd::read (this=<optimized out>,
ptr=0xffffba30, len=@0xffffb9b0: 8)
at /usr/src/debug/cygwin-3.0.1-1/winsup/cygwin/fhandler_timerfd.cc:134
[...]
This suggests to me that the slowdown comes from timerfd_tracker::wait.
The context is that emacs creates a timerfd timer that expires every 2 seconds,
'select' waits for the timer's file descriptor to be ready for reading, and
then
emacs calls 'read'.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
