Re: [RP] rpwspl behaviour

[Michael Graham]

> > > 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.
> >
> > You can sequence commands like so:
> >
> > ratpoison -c cmd1 -c cmd2 -c cmd3
> >
> > it won't return til cmd3 finishes.
>
> Mmm, that won't help though as the issue is a race between separate
> instances of the frestore, select, gselect trio used to switch
> workspaces.
>
> > 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.
>
> Yeah, I was under that impression too. But rpwspl is basically unuseable
> for me because of windows disappearing so if there is locking in there
> it's not solving the problem.

If I hadn't seen this happening myself i'd refuse to believe it!

I haven't had it happen in the last few days and had assumed it had
been caused by a bug in rpws.pl creating the wrong number of
workspaces. If you ask it to produce 6 it actually produces 7 and that
fixing that had caused the problem to go away. However if you have
produced your own scripts and the problem continues prehaps there is
more to it than that.

As a quick test, could you try

#!/usr/bin/perl -w

use strict;
use Fcntl qw (:flock);
use Getopt::Std;

my $lockfile = "/tmp/rpws.$<.lock";
open LOCK, ">>$lockfile" or die "Cannot open lockfile: $lockfile";
print "Locking $lockfile\n";
flock(LOCK, LOCK_EX);
print "hit return to release\n";
my $a = <STDIN>;  
flock(LOCK, LOCK_UN);
close LOCK;
print "released\n";

It will grab /tmp/rpws.$UID.lock (the default lock file) and if you
then try to change workspaces a few times it shouldn't do anything
(because this is holding the lock), when you exit the program above
ratpoison will jump back and forth between the workspaces. If this
happens then we know that the perl program if able to lock properly.

However the problem could be deeper than that. The perl program
perhaps isn't locking correctly under high load, to quote from the
perl cookbook [1]

File locking is not as easy as you might think  - or wish. Because
locks are advisory, if one process uses locking and another doesn't,
all bets are off. Never use the existence of a file as a locking
indication because there exists a race condition between the test for
the existence of the file and its creation. Furthermore, because file
locking is an intrinsically stateful concept, it doesn't get along
well with the stateless model embraced by network filesystems such as
NFS. Although some vendors claim that fcntl addresses such matters,
practical experience suggests otherwise.

So perhaps the following is what occurs under high load:

rpws1: test for file locked... doesn't exist
rpws2: test for file locked... doesn't exist
rpws1: lock file and continue
rpws2: lock file and continue

i.e. the delay in the test for the file lock and it being created is
long enough (under high load) for another instance of rpws to start
and test for the file lock.

I can't see any other possible way that this could be a race problem
since ratposion itself is single threaded. This doesn't rule out
another bug that causes the windows to drift from workspace to
workspace.

p.s. It just happened to me again! I noticed that the window (mozilla)
was appearing on two workspaces but if I ran allwindows.sh it was
alone reported from one. In a similar way to when you use gmove.
Moving to the next window in the workspace made mozilla return to the
correct window.

[1]http://www.unix.org.ua/orelly/perl/cookbook/ch07_12.htm
--
Michael Graham <address@hidden>