[GRASS5] R_open_driver() after fork()

Radim Blazek blazek at itc.it
Fri Feb 14 03:27:59 EST 2003

On Thursday 13 February 2003 08:58 pm, Glynn Clements wrote:
> OK; the patch works as intended, then.
> In which case, should this be changed for 5.0.x? I'm not sure that it
> should. While it does technically fix a bug, it's a bug that shouldn't
> be triggered in normal use; the situation (where a client tries to
> connect to a monitor while it is in use by another client) shouldn't
> happen.

I think that if GUI (TclTk) is used, it may happen often. Question is 
if in that case better is when module crashes or waits until the
second (first) one finishes.
Raster lib is probably stable now and no changes are expected in 5.0
so we could add patched io.c to 5.1 (where the problem appeares).

> > > In which case, we should probably set the close-on-exec
> > > flag on monitor connections:
> > >
> > > 	flags = fcntl(_wfd, F_GETFD);
> > > 	flags |= FD_CLOEXEC;
> > > 	fcntl(_wfd, F_SETFD, flags);
> > >
> > > This will force the descriptor to be closed automatically upon
> > > exec*().
> >
> > OK. Could you do that as xdriver expert?
> Well, it's a libraster issue rather than anything to do with the
> monitors themselves.
> As for implementation, again: should this go into 5.0.x?

As above, add patched io.c to 5.1.

> > > More generally, fork() and high-level APIs don't mix.
> >
> > Yes, I see, it is old story - better framework for GUI.
> I wasn't referring to GRASS APIs in particular; many third-party
> libraries have highly "undefined" behaviour w.r.t. fork().

DBMI drivers are also started by fork()+execl(), may it be a problem?
I found for example, that it is impossible to start and close more drivers
in 'FILO' order, driver opened as last must be closed first. 
Is it bug in library? Somewhere in db_shutdown_driver (driver):?
/* wait for the driver to finish */
    status = -1;
    while ((pid = wait(&status)) > 0 && pid != driver->pid) {}


More information about the grass-dev mailing list