gfxrecon-replay - handle wrap around of xcb events sequence numbers #1261
Conversation
|
CI gfxreconstruct build queued with queue ID 45799. |
|
Still working on this change, but thought I would a PR to see how it does on CI. |
|
CI gfxreconstruct build # 3217 running. |
|
CI gfxreconstruct build # 3217 passed. |
The sequence number in the cookie returned by many xcb calls (i.e. xcb_map_window) is 32 bits. The sequence number in the event returned by xcb_wait_for_event is 16 bits. When comparing the two sequence numbers to see if the xcb call has completed, mask off the top 16 bits from the cookie sequence number before doing the compare.
e953303 to
7c6857a
Compare
|
CI gfxreconstruct build queued with queue ID 46436. |
|
CI gfxreconstruct build # 3227 running. |
|
This is no longer a draft PR. I would like to have it reviewed so I can merge it. |
|
CI gfxreconstruct build # 3227 passed. |
There was a problem hiding this comment.
Looks good to me.
Alternative 1: We don't really need to change the function signatures, just the comparison (but then we'd need to mask both side of the comparison for safety).
Alternative 2: We could make EventInfo.sequence uint16_t, which would do the throwing away of bits upon assignment to it and thereby avoid the need to mask.
Took me a moment digging in to xcb docs to grok the comment. Also, arg, why is sequence 32 bit here in xcb and 16 bit there in it???
I changed the function signatures to accurately reflect what is being passed - the sequence number is 16 bits as it arrived from xcb, so we won't mislead someone reading the code that it is 32 bits. Why does xcb use 32 bits in the sequence number in the cookie that is returned by xcb calls, but 16 bits in the notification event? I started out thinking that 16 bits is used in the notification event in an attempt to save memory, since lots of events are generated. But the events are problably short-lived and the memory re-used, so the amount of extra memory used would be minimal. I dunno. |
Makes sense! I asked a friend and this is what they said:
The sequence number in the XCB API can be either 32-bit or 16-bit depending on the context. The sequence number is used to uniquely identify each request or event sent between the X client and the X server. In the XCB API, the sequence number is represented by the xcb_void_cookie_t type. This type is defined as a 32-bit value when the sequence number needs to be 32 bits, and as a 16-bit value when the sequence number can be represented by 16 bits. The reason for having both 32-bit and 16-bit sequence numbers is to optimize memory usage and network bandwidth. In situations where the number of requests or events is expected to be small, a 16-bit sequence number is sufficient and reduces the overhead of larger data types. On the other hand, in scenarios where a large number of requests or events are expected, a 32-bit sequence number is used to accommodate the larger range of values. Here are some additional details regarding the sequence numbers in the XCB API:
In summary, the sequence number in the XCB API can be either 32-bit or 16-bit depending on the situation. The choice of using a 32-bit or 16-bit sequence number is determined by factors such as the expected number of requests or events and the available resources. The XCB library handles the management of sequence numbers internally, so developers don't need to worry about it in most cases. |
The sequence number in the cookie returned by many xcb calls (i.e. xcb_map_window) is 32 bits. The sequence number in the event returned by xcb_wait_for_event is 16 bits. When comparing the two sequence numbers to see if the xcb call has completed, need to mask off the top 16 bits from the cookie sequence number.