Proposed libX11 ABI break

[Eamon Walsh]

Peter Hutterer wrote:
> On Fri, Jun 26, 2009 at 03:46:26PM -0400, Eamon Walsh wrote:
>   
>> Why don't we just not support returning XGE events from those old
>> functions ?
>>     
>
> This was the alternative towards the end of the previous email. To quote:
>   

>>> The only other solution I could come up with so far is to add XGENextEvent()
>>> and friends as substitutes for XNextEvent & co. In this approach, XNextEvent
>>> _never_ returns generic events, leaving existing clients ABI-safe.
>>> XGENextEvent requires an argument of the cookie+data type.
>>>       

New API could be conceptually cleaner and not have the cookies at all,
just return a malloc'ed buffer.  Even if you end up doing the cookie
thing, new API could bypass that and assume the caller will take care of
freeing.

>>> This approach obviously has a high cost to clients as they need to adjust
>>> for this new API.
>>>       

To update an app, new code will have to be written regardless.  I might
be naive about the relative cost of swapping out XNextEvent.  But new
API does save the cost of the ABI break and under-the-hood cookie tracking.

Actually I think everyone should switch to XCB :-).  So, take this for
what it's worth.

One more thing, with the cookie scheme, you have the following contrived
scenario:

Thread 1                  Thread 2
--------                  --------
calls XNextEvent()
                          calls XNextEvent()
                          Xlib frees previous event data
calls XGEGetEvent()
data is gone, error

Obviously you could fix this with a deeper queue, but the queue length
becomes yet another parameter that needs to be twiddled.











-- 
Eamon Walsh <ewalsh at tycho.nsa.gov>
National Security Agency