[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44320: [PATH] [27.1] Make sure send-string-to-terminal send all cont

From: Eli Zaretskii
Subject: bug#44320: [PATH] [27.1] Make sure send-string-to-terminal send all contents
Date: Mon, 02 Nov 2020 21:31:14 +0200

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: lin.sun@zoom.us,  larsi@gnus.org,  sunlin7@yahoo.com,
>   44320@debbugs.gnu.org
> Date: Mon, 02 Nov 2020 19:58:17 +0100
> On Nov 02 2020, Eli Zaretskii wrote:
> > Is EINTR considered an error for this purpose?
> Sure.

So if the call to 'write' made by 'fwrite' is interrupted by a signal,
and 'fwrite' didn't succeed to write anything, 'fwrite' will return
EOF and errno will be set to EINTR?  The proposed patch didn't handle
that case.

And if 'fwrite' was interrupted by a signal, but it succeeded to write
something, it will return a smaller count without setting errno?  Then
how to distinguish between a partial write due to a signal and a
partial write due to, say, disk full?

> > If not, what exactly is considered an error?  I don't see this clearly
> > documented, so it could be something we cannot rely on.
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fputc.html


> > In short, it sounds like calling fwrite in a loop will only work by
> > sheer luck.
> I don't see why.

Too many subtle assumptions for my palate.  In general, stdio is not
safe in the presence of signals.

Would it be better to suspend SIGIO by calling unrequest_sigio instead
(and resume it once 'fwrite' returns)?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]