This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: long I/O delays when strace is running

On 04/20/2017 08:43 AM, Gluszczak, Glenn wrote:
I haven't run Cygwin Expect for about 6 moths on Windows but it was behaving fine last time I did.
One thing I am aware of is you can't interrupt sleep in TCL.  The sleep must
complete until the Control C is processed (regardless of whether you redirected signals
to your own routines).  Otherwise signals seemed to be processed immediately.

Please note that my simplified test case isn't using expect, but the standard /usr/bin/sleep.exe -- this is just to have strace run and trace for a longer amount of time in order to expose the problem. (it did get broken into a new line though, so add a backslash:

for ((i = 0; i < 64; ++i)); do strace --output=/tmp/sleep.$$.log \
--trace-children --mask=startup sleep 64; done

Perhaps some other service is interfering.  You may want to disable other services.


I usually disable most services, I can probably disable a few more, but I would like if somebody can run the above test case in one terminal windows and in the other terminal window do a simple ps -ef and let me know if ps responds immediately or has a delay. I am using Windows 7, so it could be isolated to that windows version as well. When I do this, ps has a 3 second delay while in fhandler_base_overlapped::wait_overlapped, but I've seen this delay in other processes while calling something like "open_shared."

Anyway, I'm going to try to find another simple test case that causes more of a drastic delay.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]