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
On 02/08/18 13:12, Chris Moller wrote:
I agree with you. I'm not all that pleased with it either, mostly
because I don't understand why it works--it was something suggested
by someone on StackOverflow.
Whatever is going on seems to be the result of the EINTR out of the
fgetc()--I'll try to look more closely at that. I'll also try your
save-state suggestion. It seems to be a highly intermittent thing,
which, in combination with fork()/exec()/terminate, possibly suggests
a race condition somewhere.
--Chris
