|
From: | Chris Moller |
Subject: | Re: [Bug-apl] Yet another editor thingy. |
Date: | Tue, 7 Aug 2018 13:01:18 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
Hi, Jürgen, I finally got lucky using strace--using it affected the timing so much that at first I couldn't reproduce the failure under strace, but finally got it. What was happening was that once in a rare while, an IPC message queue in edif2 popped a signal while a character was being written to the screen by CIN, resulting in a ERESTARTSYS. I don't know if that resulted in an EINTR after the first fgetc() in LineInput::get_uni(), but it doesn't matter--LineInput::get_uni() has no way to retry the CIN write. What does cause a retry is setting SA_RESTART in my signal handlers. So far as I can tell, that fixes the problem. LineInput.cc needs one more tiny patch to remove an unnecessary step: Index: LineInput.cc =================================================================== --- LineInput.cc (revision 1061) +++ LineInput.cc (working copy) @@ -969,7 +969,6 @@ if (errno == EINTR) { clearerr(stdin); - CIN.unsetf(ios_base::unitbuf); goto again; } In addition to that first fgetc() in LineInput::get_uni(), there are two more. So far as I know, edif2 hasn't caused any signal problems with those fgetc()s, but it's not impossible. It might be worthwhile putting in some code to catch EOF/EINTR conditions on them too. --Chris On 03/08/18 16:34, Chris Moller wrote:
Hi, Jürgen, Just to keep you updated, what seems to be happening is that after a few rounds opening and closing external editor processes, the CIN << uni; in LineEditContext::insert_char(Unicode uni) isn't getting the character to the screen. I still haven't figured out why, but I'm still hacking at it. It doesn't appear to be directly related to the EINTR patch in LineInput::get_uni(), though at least stdin has to be cleared when errno == EINTR. -- Chris |
[Prev in Thread] | Current Thread | [Next in Thread] |