Какова цель последовательного параметра в API Wayland?

Question

В последнее время я работаю с протоколом Wayland, и многие функции включают параметр unit32_t serial. Вот пример из Wayland-клиент-protocol.h:

struct wl_shell_surface_listener { 
    /** 
    * ping client 
    * 
    * Ping a client to check if it is receiving events and sending 
    * requests. A client is expected to reply with a pong request. 
    */ 
    void (*ping)(void *data, 
       struct wl_shell_surface *wl_shell_surface, 
       uint32_t serial); 
    // ... 
} 

Цель этого параметра таким образом, что клиент будет реагировать с pong на сервер дисплея, передавая ему значение serial. Сервер сравнивал бы serial, полученный им через pong, с serial, который он отправил с помощью ping.

Существует множество других функций, которые включают такой параметр serial. Кроме того, реализация других функций в API часто увеличивает глобальное свойство wl_display->serial, чтобы получить новое значение serial, прежде чем выполнять какую-либо работу. Мой вопрос в том, что является обоснованием для этого параметра serial, в общем смысле? У него есть имя? Например, это вещь IPC, или обычная практика в управляемом событиями/асинхронном программировании? Разве это похоже на концепцию «cookie» XCB для асинхронных вызовов методов? Эта методика найдена в других программах (например, цитируйте примеры)?

Другим примером является перенасыщение, см. glutTimerFuncdiscussed here как «распространенная идиома для асинхронного вызова». Я хотел бы знать, имеет ли эта идиома имя, и где (пожалуйста, хорошие цитаты), это обсуждается как лучшая практика или техника в асинхронном/даже управляемом программировании, например, продолжениях или «сигналах и слотах». Или, например, как общие подсчеты ресурсов являются целыми числами, но мы считаем их «семафорами».

Answer 1

As Hans Passant и Tom Zych заявляют в комментариях, аргумент отличает один асинхронный вызов от другого.

Мне до сих пор интересно узнать о более глубоком вопросе, то есть, если этот метод обычно используется в асинхронном/управляемом событиями программном обеспечении, и если он имеет известное имя.