On Mon, 27 Aug 2018 16:15:23 +0100 Daniel Stone <dan...@fooishbar.org> wrote:
> Hi Pekka,
>
> On Mon, 6 Aug 2018 at 14:05, Pekka Paalanen <ppaala...@gmail.com> wrote:
> > On Fri, 20 Jul 2018 20:03:24 +0100 Daniel Stone <dani...@collabora.com>
> > wrote:
> > > + while (len_ > 0) {
> > > + ret = write(stream->fd, data, len_);
> > > + e = errno;
> > > + if (ret < 0) {
> > > + if (e == EINTR)
> > > + continue;
> > > +
> > > + stream_close_on_failure(stream,
> > > + "Error writing %zd bytes: %s (%d)",
> > > + len_, strerror(e), e);
> > > + break;
> > > + }
> > > +
> > > + len_ -= ret;
> > > + data += ret;
> >
> > If write() starts returning zero, we might be in for a very long loop.
>
> I don't think there's much we can do about that to be honest. I guess
> we could post an error to the owning client and disconnect it? Else
> we're just throwing away data, potentially corrupting the debug
> stream, which seems suboptimal.
>
> Currently we just block, and document that your debug client _must_
> keep up with the incoming stream.
Hi Daniel,
yes, so if write() returns zero, something is really wrong, since the
blocking behaviour is supposed to prevent that, right?
I think disconnecting the client is better than spinning forever or
losing bits of data, but is there a case where we should spin at least
a little? Implementing a timeout seems overkill and bad for other
reasons, so if occasional zero returns are normal, then the code is ok
as is.
There is also 'failure' event we could use if disconnecting is too much.
I'm also ok with not caring about this issue until someone hits it.
Thanks,
pq
pgp6Or4P4cAUR.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
