Logged In: YES 
user_id=663727

We get the same test failure with roundup-0.5.2 on Irix
6.5.5.

test/test_locking.py appears to expect that
    acquire_lock(path)
    acquire_lock(path,block=0)
should raise an exception, which (via
roundup.backends.locking and
roundup.backends.portalocker) boils down to expecting that
    file1 = open(path,'w')
    fcntl.flock( file1.fileno(), fcntl.LOCK_EX )
    file2 = open(path,'w')
    fcntl.flock( file2.fileno(), fcntl.LOCK_EX |
fcntl.LOCK_NB )
will raise an exception (presumably IOError).

On Linux (2.4.2-2 i686), it does. On Irix, it doesn't.

It's not clear to me that there is a correct behaviour
here.  If the
same process asks for an exclusive lock on the same file a
second time,should the OS respond:
(a) "No, there is already an exclusive lock on that file
(even though
    you are the process holding that lock)."
or
(b) "Sure, you can have the lock. In fact, you already had
it."

(Interestingly, if you change the code to:
    file1 = open(path,'w')
    fcntl.flock( file1.fileno(), fcntl.LOCK_EX )
    fcntl.flock( file1.fileno(), fcntl.LOCK_EX |
fcntl.LOCK_NB )
then neither Linux or Irix raise an exception. That is, when
the same
process re-requests a lock on the same file, Linux makes a
distinction
based on whether the request is made via the same file
descriptor or
not. This seems very odd to me, since locks are on files,
not file
descriptors.)

Anyway, I'm wondering if roundup actually relies on the
behaviour that
this test case expects. That is, might a roundup process
actually try
to obtain multiple locks on the same file?

(My suspicion is that roundup only requires that *different*
processes
can't both acquire exclusive locks on the same file. *That*
works on
both Linux and Irix, but it isn't what the test case is
testing.)