[GRASS5] Platform for next generation UI

[Glynn Clements]

=?ISO-8859-13?Q?M=E2ris_Narti=F0s?= wrote:

> > Each module would need to acquire locks on all of the maps which it
> > will be using at the outset, and release them all upon completion.
> >
> > This really needs to be done in the module itself, as the libraries
> > only get to "see" individual maps being opened and closed.
> 
> For non-programmer it seems to be trivial -
> G_open_raster_new() - deadlock;
> G_open_raster_old() - softlock.

I presume that you mean write-lock/read-lock.

The problem is that a module needs to obtain all of the locks it
requires before it starts doing anything. Otherwise, it could end up
in a situation where it discovers it cannot complete (due to deadlock)
after it has already made some of the changes to the mapset.

Consequently, the locking has to be done by the module; it can't be
done by individual libgis functions.

> Only big problem - what if module forgets to call G_close_cell() (i.e.
> segfaults).

Use kernel locks (flock/lockf/fcntl); those are released automatically
when the process which owns the lock terminates.

That still doesn't solve the problem of inheriting locks. If one
module invokes another to do its work, the caller must lock the
relevant maps at the outset, and the callee must be able to inherit
the lock.

-- 
Glynn Clements <glynn at gclements.plus.com>