[Gambas-devel] Question about singleton class

Tobias Boege taboege at ...176...
Sat Sep 13 15:17:12 CEST 2014


On Sat, 13 Sep 2014, John Leake wrote:
> Hi Tobi,
> Thank you for your response and confirming the same behaviour. Sorry for
> the break point I left in the code and a path that was not relevant to
> your test.
> 

No need to excuse.

> If you step back from the detail and look at this from a programming
> perspective and look at the gambas docs then it appears to be a bug.
> 

Something that could be fixed by inserting "this works with POSIX locks;
expect POSIX lock behaviour" into the documentation doesn't seem to be a
bug to me. But this sort of thing is Benoit's realm.

> I have looked at the code but cannot quite work out where the bug is.
> This is not because it is written in C but more to do with following the
> program flow.
> 
> Do calls to THROW return ?
> 

Knowing C is far away from knowing "Gambas interpreter C", I can tell ;-)

ctags is of some help for me. THROW calls PROPAGATE which, in turn, does a
longjmp(), so it doesn't return.

However, it sort of returns when you are in your own TRY block (it then
continues in your CATCH block). If you look at main/gbx/gbx.c, you see that
the event loop is started from inside a TRY block, so if there are no other
TRYs down your path and the Gambas program itself doesn't provide some Try/
Catch/Application_Error logic, a THROW will kick you back right to the
interpreter's main() function which reports the error.

(You should read the above paragraph with an "I guess" prefixed to every
 sentence! The interpreter internals aren't my domain.)

> Anyway could I be bold and suggest what should happen and how it can be
> implemented:
> 
> If a proc is granted a write Lock it should obviously be an exclusive
> lock and remain in place until Unlock is called or the proc terminates.
> All OS write lock mechanisms do this no matter whos standard you look
> at. If the same proc calls Lock a second time without calling Unlock in
> between then the original lock should be left in place and a 'no-error'
> status returned to the caller.
> 
> To achieve this simply retain the file handle to the locked resource and
> keep it open until Unlock is called or the proc dies/exits.
> 

Yes, this is exactly how it is supposed to be done... by the Gambas
programmer. This is the solution I advised in my last mail.

You get the file handle in a Stream object from the Lock instruction. If
you, as a programmer, drop the last reference count of that object and
thereby close the stream, this is exactly what unlocks a POSIX lock. You
may have done that by accident, but that's what happened.

I would agree that a note in the docs is due that closing a lock Stream
is the same as unlocking it and that you can close your stream in some
subtle ways such as the above one.

> >> 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".
> > 
> Are you saying that Try followed by a test on Error is not the right way
> to code in Gambas ?
> 

Yes it is. You often see code like

  Try ' this and that
  If Error Then
    ' Try to recover / display an error
    ' Most likely a Return here
  Endif
  ' Continue

but Error.Text is set only when a new error happens. Things going well
don't affect its value. It's much like the errno variable.

> > 
> >> 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.
> > 
> So do you mean that to use Lock and Unlock an app also has to Delete files ?
> 

By no means I meant that. Apparently, removing a lock and removing a
*lock file* are two different things.

Regards,
Tobi

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




More information about the Devel mailing list