GNU bug report logs - #44320
[PATH] [27.1] Make sure send-string-to-terminal send all contents

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: larsi <at> gnus.org, sunlin7 <at> yahoo.com, 44320 <at> debbugs.gnu.org, lin.sun <at> zoom.us
Subject: bug#44320: [PATH] [27.1] Make sure send-string-to-terminal send all contents
Date: Mon, 02 Nov 2020 18:14:56 +0200

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: LinSun <lin.sun <at> zoom.us>,  larsi <at> gnus.org,  sunlin7 <at> yahoo.com,
>   44320 <at> debbugs.gnu.org
> Date: Mon, 02 Nov 2020 16:49:49 +0100
> 
> >> write(6, "…", 256) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
> >
> > Thanks.
> >
> > I don't think I know how to interpret this trace, or understand the
> > significance of ERESTARTSYS.
> 
> It is translated to EINTR on signal handler return:
> 
> rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
> 
> Outside of strace, ERESTARTSYS is never observed by user-space.

So you are saying that the call to 'write' issued by 'fwrite' or
'fflush' was interrupted by SIGIO, and that is why it didn't write all
of its data?  IOW, the size of the string passed to 'fwrite' has no
real significance here, and instead the problem is the signal?

If so, is it normal for 'fwrite'/'fflush' to punt instead of
continuing its 'write' loop upon receiving EINTR?  I can understand
why we need a loop when we call 'write' directly, but I'd expect
'fwrite' to do that internally.  Am I naïve?

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.