[PATCH] os: Don't write the reply that overflows output buffer

Kristian Høgsberg krh at bitplanet.net
Mon Aug 2 16:58:47 PDT 2010

On Mon, Aug 2, 2010 at 2:36 PM, Keith Packard <keithp at keithp.com> wrote:
> On Mon,  2 Aug 2010 11:29:55 -0400, Kristian Høgsberg <krh at bitplanet.net> wrote:
>> Here's the other approach for fixing damage vs flush client.  In writing the
>> commit message, it certainly does feel like damage should just be fixed to
>> not reply on that behaviour.  And writing the patch, I realize that the
>> optimization is not just about saving a syscall, but also about avoiding
>> having to realloc the output buffer to hold a request that's bigger than
>> BUFSIZE (hello, XkbSendMap()).  The current code only does that when it
>> fails to write the output buffer + extra request and the remaining bytes
>> don't fit in a standard sized buffer.
> This doesn't really fix the issue as we're potentially sending a stream
> of events from the damage extension. We'd have to buffer all of them
> until FlushAllOutput, I think.

Ah, yes, I see the loop over the damage region boxes, should've
checked that.  It was pretty fragile to rely on that guarantee anyway;
if we want the rendering to happen before the event is sent, we should
do the rendering before we send the event.

> It is a nice cleanup though; let's look at this post-1.9 separately.

Maybe - the old code had the benefit of typically not having to
allocate a big buffer for big events. It would just add the big buffer
that overflowed the protocol buffer to the writev request and avoid
the copy.  And if I don't have to touch low level protocol code, I'd
rather not.


More information about the xorg mailing list