Red Hat угощает Wayland-ом разработчиков Firefox

Ну вот мне тоже кажется что

• использовать сокетный буфер для хранения очереди это тупняк

• unbound очереди приводящие к oom это смех.

Так это равносильно закрытию сокета.

Почему вообще какая-то очередь может переполниться? Почему размер этой очереди не динамический?

Тебе уже выше написали почему :))

Не убедительно.

Да нет, там все очень наглядно: зависший клиент приводит к oom сервера.

С чего бы вдруг? Сокет остаётся открытым и мы ждём пока в ядерной очереди сообщений появится свободное место. Ждать можно неограниченно долго, это локальный UNIX сокет, а не TCP, там таймаутов нет.

С чего бы вдруг? Сокет остаётся открытым и мы ждём пока в ядерной очереди сообщений появится свободное место. Ждать можно неограниченно долго, это локальный UNIX сокет, а не TCP, там таймаутов нет.

И копим на стороне сервера? Тебе уже показали, что будет OOM. Начинаем дропать сообщения? У тебя неконсистентный стейт. В итоге, когда клиент возвращается, ему нужно прислать весь стейт целиком. Что равносильно новому подключению :)

Кольцевой буфер – это внутреннее состояния клиента/сервера в libwayland. Head/tail наружу не передаются и их можно поменять при реаллокации буфера. Для коммуникации используется ядерная очередь сокета.

Не надо ничего копить. Достаточно хранить два состояния: состояние ввода клиента на момент зависания и состояние ввода сервера. При развисании достаточно передать только разницу между двумя этими состояниями.

Не надо ничего копить. Достаточно хранить два состояния: состояние ввода клиента на момент зависания и состояние ввода сервера. При развисании достаточно передать только разницу между двумя этими состояниями.

Это равносильно новому подключению.

Нет же. Достаточно отправить разницу состояния ввода. Не надо заново пересоздавать все окна, буферы, контекст OpenGL/Vulkan и т.д..

Нет же. Достаточно отправить разницу состояния вводаю. Не надо заново пересоздавать все окна, буферы, контекст OpenGL/Vulkan и т.д..

Это выглядит «просто» на бумаге, пока ты не вспоминаешь что клиенту нужно размапливать fd, кешировать изменения и прочий блуд. И если ты хочешь «отправить разницу», теперь и клиенту и серверу нужно уметь получать какой-то жирнейший diff, который будет 1-1 соотносится с полследовательностью происходивших ивентов.

что клиенту нужно размапливать fd

Зависшему клиенту нет необходимости проводить манипуляции с FD и буферами. Он ничего не рисует. Сервер будет просто показывать последний заданный буфер.

Сделать разницу для событий ввода особых трудностей не составляет. Также как не составляет труда сделать разницу для событий изменения размера окна (хранить последний клиентский и серверный размер) и прочее.

В Windows это было сделано начиная с версии 1.0 и никаких особых трудностей с реализацией не было.

Есть одна трудность — для такого нужны адекватные разработчики.

Зависшему клиенту нет необходимости проводить манипуляции с FD и буферами. Он ничего не рисует. Сервер будет просто показывать последний заданный буфер.

Это если ему ничего не прислали. А прислать могли.

Сделать разницу для событий ввода особых трудностей не составляет. Также как не составляет труда сделать разницу для событий изменения размера окна (хранить последний клиентский и серверный размер) и прочее.

Сделай!

Сделай!

А толку, в апстрим не примут. Сколько раз уже отклоняли патчи с нормальными фичами потому что «мы так видим».

Да, протолкнуть это будет трудно потому что ломается libwayland API.

Да, протолкнуть это будет трудно потому что ломается libwayland API.

Лулз в том что ничего нигде не ломается, просто в лялексе до сих пор не могут дойти до одной простой мысли: UI должен быть развязан с логикой и сидеть в разных тредах. А не ломается потому что очередь ивентов на стороне libwayland-client ВНЕЗАПНО ЕСТЬ. Ну и таймаут в 5 секунд на стороне гнома это мало.

делились советами не двигать мышкой когда открыт Firefox

2023, редхат, итоги

но года 3 ещё побуду на X-ах

Я бы не загадывал, может, больше.

А не ломается потому что очередь ивентов на стороне libwayland-client ВНЕЗАПНО ЕСТЬ.

От этой очереди нет никакого толку потому что отправка сообщений сервером неблокирующая и нет никаких механизмов определить что очередь клиента переполнена. То есть нет возможности узнать убъёт ли соединение отправка очередного сообщения клиенту или нет.

Пока мне лишь очевидно, что ограничения на размер очереди выбраны неудачно. Не обязательно оомить сервер. Можно и что-то посредине выбрать. Несколько тысяч сообщений вряд ли занимают больше нескольких десятков килобайтов.

От этой очереди нет никакого толку потому что отправка сообщений сервером неблокирующая и нет никаких механизмов определить что очередь клиента переполнена. То есть нет возможности узнать убъёт ли соединение отправка очередного сообщения клиенту или нет.

Лолшто?

server: cannot write to socket: Resource temporarily unavailable

Развлекайся:

#include <err.h>
#include <stdio.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>

int
main(void)
{
	int ret;
	int sock;
	int csock;
	struct sockaddr_un sa = {0};
	static const char data[1024];

	sa.sun_family = AF_UNIX;
	snprintf(sa.sun_path, sizeof(sa.sun_path), "%s", "/tmp/uds.sock");

	sock = socket(AF_UNIX, SOCK_STREAM, 0);
	if (sock == -1)
		err(1, "cannot open socket");

	unlink(sa.sun_path);
	ret = bind(sock, (const struct sockaddr *)&sa, sizeof(sa));
	if (ret == -1)
		err(1, "cannot bind to %s", sa.sun_path);

	ret = listen(sock, 10);
	if (ret == -1)
		err(1, "cannot listen on %s", sa.sun_path);

	csock = accept4(sock, NULL, 0, SOCK_NONBLOCK);
	if (csock == -1)
		err(1, "cannot accept new connection");

	for (;;) {
		ret = write(csock, data, sizeof(data));
		if (ret == -1)
			warn("cannot write to socket");
	}

	return 0;
}

Это не то. Это через голые сокеты, а не libwayland-server. Понятное дело что можно сделать корректную обработку зависания клиентов если выкинуть на помойку libwayland-server.

Это не то. Это через голые сокеты, а не libwayland-server. Понятное дело что можно сделать корректную обработку зависания клиентов если выкинуть на помойку libwayland-server.

Это неблокирующая работа сокетов. Запись в сокет никого не убивает, лол. Композитор закрывает клиентский сокет если тот ему на пинги раз в пять секунд не отвечает.

Вызов например wl_pointer_send_motion убъёт соединение при переполнении очереди и никак это распознать нельзя, API такого нет.

Вызов например wl_pointer_send_motion убъёт соединение при переполнении очереди и никак это распознать нельзя, API такого нет.

Г-ди иисусе.. никто никого не убьет:

	if (mask & WL_EVENT_WRITABLE) {
		len = wl_connection_flush(connection);
		if (len < 0 && errno != EAGAIN) {
			destroy_client_with_error(
			    client, "failed to flush client connection");
			return 1;
		} else if (len >= 0) {
			wl_event_source_fd_update(client->source,
						  WL_EVENT_READABLE);
		}
	}

Вот код который в сокет пишет. Он проверяет на EAGAIN. Если очередь сокета переполнилась, он уходит на круг и ждет когда WL_EVENT_WRITABLE снова поставят.

wl_pointer_send_motion пишет в кольцевой буфер, при переполении которого вызывается wl_connection_flush. Если wl_connection_flush вернул ошибку, то прибивается соединение.

https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/wayland-server.c?ref_type=heads#L234

No, that does not work in general. If the compositor gets EAGAIN and the libwayland-server buffer is already full, then the server has no place to store the message it needs to send. It has to drop the message.

Ну и тыдыдын. Очереди есть, лимит на них тоже есть, в итоге очереди переполняются и приехали. Все как и хотели.

В нормальных GUI системах wl_pointer_send_motion заблокируется, а не прибъёт соединение в таком случае.

В нормальных GUI системах wl_pointer_send_motion заблокируется, а не прибъёт соединение в таком случае.

Заблокировав вообще всех клиентов? Отличная GUI система, уносите.

Заблокирует поток обработки конкретного клиента. Ах да, забыл, в Линуксах многопоточность не умеют. Верят в святой epoll.

Заблокирует поток обработки конкретного клиента.

По треду на клиент? От этого ушли все кто к этому приходил. Браузеры, nginx, Linux workqueues, файловые системы.

В Windows так с времён Windows 95, NT 3.1 до настоящего времени. Можно хоть каждую кнопку в отдельном потоке запускать.

В Windows так с времён Windows 95, NT 3.1 до настоящего времени. Можно хоть каждую кнопку в отдельном потоке запускать.

Что угодно можно запускать в отдельном потоке, но перфоманс начинает сосать настолько сильно, что от этого отказываются.

В Windows нет никаких проблем с производительностью связанных с многопоточной графикой. В Haiku также применяется многопоточная графика по паре потоков клиент-сервер и по ощущениям оно отзывчевее многих линуксов.

nginx

Задачи тут другие, нет необходимости обслуживать миллион GUI клиентов.

В Windows нет никаких проблем с производительностью связанных с многопоточной графикой.

В windows окна постоянно виснут, лол. Я не помню чтобы я такое в лялехе встречал.

В windows окна постоянно виснут, лол.

Зато не падают рандомно. Виснут окна из-за багов конкретных программ, а не GUI подсистемы Windows.

Представьте редактирую я сложный документ и вдруг всё падает и я теряю результаты работы из-за неосторожного движения мышью. Пусть уж лучше оно виснет, чем падает. Так данные будут целы.

Представьте редактирую я сложный документ и вдруг всё падает и я теряю результаты работы из-за неосторожного движения мышью. Пусть уж лучше оно виснет, чем падает. Так данные будут целы.

Поэтому все клиенты должны научиться переживать разрыв соединения, лол. Чтобы потом не началось «ололо мой композитор сдох и все программы сдохли».

Композитор и соединение не должны дохнуть ни при каких обстоятельствах. Это фатальный баг ОС и его надо исправлять. И нечего городить костыли с переживанием разрыва соединения.

Вот гады в вантузе нагородили переживание краха видеодрайвера…

Композитор и соединение не должны дохнуть ни при каких обстоятельствах. Это фатальный баг ОС и его надо исправлять. И нечего городить костыли с переживанием разрыва соединения.

Бвахаха. Кеды пытаются это сделать годами и у них не особо получается. Так что нет, сорян, это необходимый процесс и Qt уже его сделали. Осталось дождаться Gtk.

Это происходит полностью прозрачно для клиентов. Состояние окон не теряется. Пересоздавать никаких соединений не надо.

Но вообще говоря, сделоц ручку со сторны libwayland-server для установки максимального размера ринга сообщений – нормальная идея.

Пересоздавать никаких соединений не надо.

Когда драйвер дохнет? Там весь стейт напрочь инвалидируется.

Проблема ещё в том, что часть состояния Wayland сервера недоступна клиенту так что часть состояния будет потеряна при переподключении. Например окна будут пересозданы в рандомных местах и без сохранения Z-order.

Проблема ещё в том, что часть состояние Wayland сервера недоступна клиенту так что часть состояния будет потеряна при переподключении. Например окна будут пересозданы в рандомных местах и без сохранения Z-order.

Это политика композитора, как решит так и будет. Не вижу проблемы сделоц со стороны композитора зомби окна, которые могут быть восстановлены при реконнекте в течении минуты, например.

Состояние окон (позиция, размер, стиль и т.п.) вообще не имеют никакого отношения к драйверу.

Состояние окон (позиция, размер, стиль и т.п.) вообще не имеют никакого отношения к драйверу.

Не имеют. А их содержимое – ещё как :D

Каким чудом сервер узнает какие новые пересозданные окна соответствуют старым до разрыва соединения?