> On Sep 18, 2016, at 09:58, Keith Packard <kei...@keithp.com> wrote:
> Matthieu Herrb <matth...@herrb.eu> writes:
>> this doesn't fix an issue I'm seeing on OpenBSD with xterm not beeing
>> able to start (it makes the X server spin at 100% CPU in
>> WaitForSomething()), while Jeremy's patches do fix the issue for me.
> I think Jeremy's patch will cause the server to spin while any client is
> not writable, which isn't good.

I don't believe that is the case because ClientReady does:

ospoll_mute(server_poll, fd, X_NOTIFY_WRITE);

If I read the flow right, the level trigger causes WaitForSomething to spin up 
only when a client is ready to receive data.  ClientReady then mutes the 
trigger.  FlushClient then possibly re-enables it if we EAGAIN.  If/when the 
client is ready again (level trigger), ClientReady will fire again.

If the client is not ready to receive data, ClientReady won't fire.

My patch does indeed cause us to needlessly FlushAllOutput() if something else 
(eg: a new connection, new request) causes WaitForSomething() to spin up, but 
that's no different than someone currently just setting NewOutputPending=YES 
even though there is no pending output.

>> I've not been able to really understand the issue yet, but that's a
>> data point. (And I'm glad to see that it doesn't seem to be an OpenBSD
>> specific issue :)
> I'd bet anyone using poll(2) instead of epoll(2) will see the same
> problems. It should be possible to reproduce this on Linux by using the
> poll path instead of epoll.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to