|
|
|
|
|
|
by cycloptic
2059 days ago
|
|
|
I hear what you're saying and I also can't stand the namecalling and political infighting that tends to happen in some open source communities. Unfortunately I doubt a display protocol is ever going to fix that. On that bug, that problem seems to go deeper than Wayland and I don't know if there is any way to fix that in all cases on Linux due to the nature of SIGSTOP. I know you may not answer this, but wouldn't that also affect X too? Or does it have some other way it deals with it? |
|
|
The way the disconnect happens is interesting though, I am not certain enough about the threaded-IO implementation in regards to hotplug but a quick glance looks like if a hotplug occurs at the same time a client is disconnected the sparse allocation requirement of open() could get an input device confused as a client as it is cleaned up. The odds of that happening though :D
In the wayland code it looks like they tried to have a buffer strategy at some point, but then got too clever for their own good (epoll designs + asynch-OO projected over C is... yeah) and somewhere in 'closure/write/buffering to lower #syscalls/callbacks' landed in a long chain of error propagation and immediate kill.
The best way I found (hence using it) is to have memory mapped ring buffers and just have an atomic head-tail indicator. This makes file-descriptor transfers (DuplicateHandle from win32 fame is just so much prettier) messier, but it means that you can have a recovery strategy and see the backpressure buildup and rate-limit. Since it is mostly input events or 'drag-resize' (and those can be merged) in that direction, silently dropping them and have mouse cursor 'jank' is better than losing your work. If all else fails, the watchdog handle is pulled and the client is set to migrate to a fallback server (if set).