ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RP] rpwspl behaviour


From: Shawn Betts
Subject: Re: [RP] rpwspl behaviour
Date: Tue, 09 May 2006 23:44:00 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix)

Matthew Sackman <address@hidden> writes:

> Hi,
>
> Is it just me or do other people suffer from windows either leaking from
> one group to another or windows vanishing completely? This tends to
> happen when switching rapidly between workspaces whilst under heavy
> load.
>
> What I think is happening is that ratpoison is being told to switch to a
> group and restore frames and is then told to switch to another. When
> switching to another, the group selection hasn't taken effect yet so
> ratpoison reports the wrong current group thus leading to groups getting
> lost. Is this possible - is there a race condition here that ratpoison
> can be sent a gselect and then groups and the groups output not reflect
> the result of the gselect?
>
> I thought initially this was rpwspl's fault so wrote my own scripts to
> achieve the same thing through different means. But occasionally I get
> the same behaviour - under 100% load switch to wsA and then to wsB
> before wsA has been loaded. In switching to wsB, the contents of wsA are
> saved (group selection and frames) but it's in fact the current workspace
> that is saved as wsA because wsA was never loaded. Thus wsA in effect
> vanishes (other than manual gselect). So can ratpoison be made to buffer
> commands and only honour them in order, such that the next won't be
> started until the current has completed?

You can sequence commands like so:

ratpoison -c cmd1 -c cmd2 -c cmd3

it won't return til cmd3 finishes.

You might also want to create a lock file so the script blocks until
the lock is released. I somehow thought there already was locking to
address this or a very similar issue.

-Shawn




reply via email to

[Prev in Thread] Current Thread [Next in Thread]