Synchronizing _NET_WM_STATE writes and reads
m.kaeppler at googlemail.com
Fri Nov 9 03:09:41 PST 2007
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.
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
> > 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.
Knowledge Management Group
DFKI GmbH, Germany
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xorg