Re: [PATCH] error handling: Use TFR() macro where applicable

[Peter Maydell]

On Fri, 5 Aug 2022 at 12:27, Marc-André Lureau
<marcandre.lureau@redhat.com> wrote:
> On Fri, Aug 5, 2022 at 3:11 PM Christian Schoenebeck
> <qemu_oss@crudebyte.com> wrote:
> > I was thinking the same as Marc-André before:
> >
> > commit 1dacd88ddcf33eb6ed044c4080e3ef5e3de4b6b6
> > Author: Marc-André Lureau <marcandre.lureau@redhat.com>
> > Date:   Wed Mar 23 19:57:27 2022 +0400
> >
> >     include: move TFR to osdep.h
> >
> >     The macro requires EINTR, which has its header included in osdep.h.
> >
> >     (Not sure what TFR stands for, perhaps "Test For Retry". Rename it ?)
> >
> >     Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> >     Message-Id: <20220323155743.1585078-17-marcandre.lureau@redhat.com>
> >     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> >
> > Wouldn't it make sense to first rename TFR() to something like
> > RETRY_ON_EINTR() and then doing this consolidation here on top?
>
> Apparently TFR often stands for "Temp Failure Retry" (looking at
> github code search)
>
> LOOP_WHILE_EINTR ?

At the risk of getting into bikeshedding, since glibc's unistd.h
defines a TEMP_FAILURE_RETRY() macro for this purpose, maybe we
should use that, with a thing in osdep.h for "provide this macro
if the system headers don't [ie musl, BSDs, Windows, etc]" ?

(There is a subtle difference between our TFR() and the glibc
TEMP_FAILURE_RETRY(): TEMP_FAILURE_RETRY() casts the result
of the expr to 'long int' before comparing for equality with -1.)

More generally, I think we should either use this macro rather
more widely, or get rid of it entirely. The current situation
where we use it in some of the net/tap code and a few chardevs
and basically nowhere else is not very satisfactory.

thanks
-- PMM