LINUX.ORG.RU

В каком месте XCB «асинхронный»?

 ,


0

0

Вместо ответов на запрос он возвращает так называемые cookies, по которым можно получить ответ. И ждать ответа с использованием cookies надо — та-дам! — синхронно, блокируясь. Это вместо действительно асихронных колбэков.

Конечно, вы можете сказать, что cookies это Futures, а Futures это более лучший, более высокоуровневый механизм, чем колбэки. Но Futures хороши когда они и правда высокоуровневые и предоставляют, например, возможность их композиции. А куцые Futures, типа XCB cookies, хуже колбэков. IMO.

Зачем футуресы в С? Ты просто не знаеш как работает иксовый протокол

anonymous ()

Ты опоздал со вбросом на N лет, сейчас актуально вбрасывать про Wayland.

anonymous ()

xcb_poll_for_reply тогда для чего

anonymous ()
Ответ на: комментарий от anonymous

Зачем футуресы в С?

Вот и я об этом спрашиваю.

Ты просто не знаеш как работает иксовый протокол

Да что там знать. Отправил запросы, получил ответы. Порядок последних полностью определён порядком первых. В этом смысле протокол абсолютно синхронный.

utf8nowhere ★★ ()
Ответ на: комментарий от utf8nowhere

спросил, если нет, пошёл заниматься своими делами или уснул

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от utf8nowhere

Я без понятия, как xcb предлагает ранлупиться, просто заинтересовался и нагуглил функцию. Думаю он вообще никак не предлагает, как и положено библиотеке.

https://lists.freedesktop.org/archives/xcb/2008-August/thread.html#3674

Обсуждение вариантов интеграции.

anonymous ()
Ответ на: комментарий от Dark_SavanT

Так нельзя, будешь опоздывать на ивенты.

anonymous ()
Ответ на: комментарий от anonymous

Обсуждение вариантов интеграции.

Я так понял, xcb_get_event_file_descriptor не приняли.

Варианты интеграции известен: достать дескриптор (xcb_get_file_descriptor()) и совать его в select, epoll etc.

Типа как здесь:

xcb_get_file_descriptor и потом xcb_poll_for_event

Это тред не про вариант интеграции, а про странное определение «асинхронности».

utf8nowhere ★★ ()
Ответ на: комментарий от utf8nowhere

Колбечная асинхронность неразрывна в ранлупом. Подумой, если xcb не реализует ранлуп, то и стрелять колбеками не ему.

anonymous ()
Ответ на: комментарий от anonymous

xcb_poll_for_reply тогда для чего

https://xcb.freedesktop.org/ProtocolExtensionApi/

These functions are expected to be useful only to X protocol extension implementations built on XCB.

Вот для чего.

utf8nowhere ★★ ()
Ответ на: комментарий от utf8nowhere

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

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

Пока окно не отрисуется полностью, в ответе будет рыбья чешуя

А подробнее?

utf8nowhere ★★ ()
Ответ на: комментарий от utf8nowhere

А подробнее я отложил эту задачу на попозже и сейчас занимаюсь другим. Но если кратко, то, получив куку и попытавшись у нее сразу узнать на каком воркспейсе мое окно открылось (WID уже есть), я всегда получаю воркспейс=0, а перед закрытием окна из той же куки я получаю правильный номер воркспейса (от 0 до 3 в моем частном случае).

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

И чем это не синхронно, если все равно требуется ожидание ответа?

mersinvald ★★★★★ ()
Ответ на: комментарий от mersinvald

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

deep-purple ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.