[Gambas-devel] Question about singleton class

[Tobias Boege]

On Fri, 12 Sep 2014, John Leake wrote:
> Hi All,
> I have some unexplained behaviour relating to the Lock and Unlock
> functions. Attached is a small project that allows you to call
> Lock/Unlock at will. It shows the return status of Error.Text following
> a Try call.
> 
> I have spent several hours searching the source tree and cannot find the
> implementations of Lock and Unlock in order to suggest a fix (assuming
> of course that there is a problem in the first place and I have not done
> something stupid in the source).
> 
> Does anyone know where the implemented source is for version 3-3.5.4 ?
> 

It's in main/gbx/gbx_subr_file.c:SUBR_lock. From there it will take you to
main/gbx/gbx_stream.c:STREAM_lock.

> The Problem
> -----------
> 
> If you launch several instances of the executable
> SystemwideSingleton.gambas and you Attempt to Lock twice from the same
> instance then:-
> 1) The second call does not return an error or any idea that you already
> have lock.

Allegedly[0] this is by design. Multiple POSIX locks on the same file from
the same process never conflict.

> 2) Worse still if you then go to a different instance and Attempt a Lock
> it returns no error and you end up with both instances believing they
> have exclusive Lock on the file.

First, I run your project in a slightly modified version: I needed to change
the path to the lock because I'm not "john", and you had a breakpoint set in
the IDE on line 28. This makes the program stop. Obviously I needed to remove
it.

Then, what you mentioned above only happens to me when I acquire the lock in
one process and then acquire it again from there. Then I can get the lock
from the other process, too.

This is also to be expected. The article [0] says:

  "More troublingly, the standard states that all locks held by a process
   are dropped any time the process closes any file descriptor that
   corresponds to the locked file"

When you lock the file again, the code

  Try h = Lock f

in your function is executed again which drops the last reference count of
the object in the variable h (NB: *after* the Lock instruction was executed)
and thus destroys the object, which closes the stream and releases the
lock(s), in accordance with the standard.

You would modify your function to first test if h is already an object
(different from Null) and if it is, then you bail out of your locking
attempt.

> 3) Starting from scratch. Attempt to Unlock the file and you see an
> error returned which is OK. But when you then Attempt Lock it returns OK
> but the empty string from Error.Text does not wipe out the previous
> error text. Surely I am doing something wrong in the code ?

No you don't. Error.Text "returns the last error message".

(It isn't automatically cleared once you read its value or any other action
is carried out because we then would have the trouble of defining what an
"action" is in the interpreter and insert clear calls everywhere, risking
that the information is erased before the user could see it.)

> 4) How can an app decide when to clean up and remove the lock file ?
> 

I don't think I get your question right but in case I do, I'd say: It
removes the lock when it's done with its job. When this event occurs
must be wired into the program's logic.

Regards,
Tobi

[0] http://lwn.net/Articles/586904/

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk