Synchronizing _NET_WM_STATE writes and reads

[Matthias Käppler]

Peter,

thanks a lot for your valuable input. The more I think about it, the less
does it seem to be an issue for us anyway, since instantaneous calls to
changing a window's visibility and then reading its states again is very
unlikely to happen in the deployed environment. I just stumbled across this
behavior when running a unit test where I do something like this:

1. set some visibility state, e.g. maximize a window
2. read the states the WM set for this window
3. assert that the proper states are set for this window

Since these steps happen in a matter of milliseconds, there is simply not
enough room for the window manager to catch up. But, as I said, this is very
unlikely to happen in the actual program so I'll just ignore it for now.

Best regards,
Matthias

2007/11/9, Peter Hutterer <mailinglists at who-t.net>:
>
> Matthias Käppler wrote:
> > What if the client triggers a state change and some other client wants
> to
> > retrieve information about that window shortly thereafter? I need pull
> > semantics where clients are able to retrieve the currently active states
> > instead of pub/sub semantics.
>
> the problem is not unfamiliar to the synchronisation issues in
> multithreaded environments.
>
> you're basically calling for making the action and setting of the
> property an atomar operation. this is hard enough for simple operations
> like incrementing a variable, making something complex like changing a
> window's properties a window and then setting an atom on the X server
> indivisible doesn't make it easier.
>
> so no - I don't think there's a way to get around it.
>
> Cheers,
>    Peter
>
>
>


-- 
Matthias Käppler
Research Assistant
Knowledge Management Group
DFKI GmbH, Germany
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20071109/5339bf81/attachment.html>