Hacker News new | ask | show | jobs
by josefx 1008 days ago
> clients relied on memory stored by the Xserver, they made synchronous calls that were expected to return values, and multiple clients talked to multple clients.

Wasn't that just an issue with the Xlib interface? I thought Xcb made everything async.
1 comments
vidarh 1008 days ago
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.

link
hulitu 1008 days ago
> 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.

link
vidarh 1008 days ago
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.

link