On Fri, Nov 12, 2021 at 12:24:06PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Thu, Nov 11, 2021 at 7:44 PM Roman Kagan wrote:
>
> > As its name suggests, ChardevClass.chr_sync_read is supposed to do a
> > blocking read. The only implementation of it, tcp_chr_sync_read, does
> > set the underly
Hi
On Thu, Nov 11, 2021 at 7:44 PM Roman Kagan wrote:
> As its name suggests, ChardevClass.chr_sync_read is supposed to do a
> blocking read. The only implementation of it, tcp_chr_sync_read, does
> set the underlying io channel to the blocking mode indeed.
>
> Therefore a failure return with E
As its name suggests, ChardevClass.chr_sync_read is supposed to do a
blocking read. The only implementation of it, tcp_chr_sync_read, does
set the underlying io channel to the blocking mode indeed.
Therefore a failure return with EAGAIN is not expected from this call.
So do not retry it in qemu_
