[vidarh]

Yeah, very little in the protocol is sync. E.g. when you create a window the client picks the id, and you just go on assuming it will be created until/unless an error arrives.

Only things explicitly querying for information is "somewhat" sync, but then too the reply will arrive back with a sequence number, so the client API can just keep returning events and hold on to the replies until you ask for them.

X has many warts, but it being synchronous isn't one of them.

[hulitu]

> X has many warts, but it being synchronous isn't one of them.

I seem to remember that there was a command line switch to run X (or some clients) in syncronous mode. It was mostly used for debugging.

[vidarh]

Xlib is peculiar in that it doesn't really expose you to the protocol very well. For starters, it doesn't immediately write every request. Partly because it saves bandwidth on slow networks to not send lots of tiny requests that might end up in separate packets.

Partly because the Xlib API is pathological in making it hard for you to minimize requests yourself. E.g. a lot of calls to modify graphics contexts can be batched up, but that requires Xlib to not worth requests immediately.

So hence there being some value on testing with different flush behaviour.

But this is Xlib specific, not really X.