[GRASS5] R_open_driver() after fork()
glynn.clements at virgin.net
Thu Feb 13 14:58:59 EST 2003
Radim Blazek wrote:
> > With the patch, R_open_driver() shouldn't hang indefinitely in
> > sync_driver(); you should get a warning after 5 seconds then failure
> > after a further 10 seconds (15 seconds total). Basically, the second
> > R_open_driver() call should eventually fail, rather than blocking
> > indefinitely.
> > If SIGALRM fails to interrupt the read() call even with the patch,
> > then your OS kernel is broken.
> Yes, I have got:
> Warning - no response from graphics monitor <x0>.
> Check to see if the mouse is still active.
> ERROR - no response from graphics monitor <x0>.
> Monitor <x0>: Caught SIGPIPE
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
> > Presumably the child calls one of the exec*() functions shortly after
> > the fork()?
> > 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
As for implementation, again: should this go into 5.0.x?
> > 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().
Glynn Clements <glynn.clements at virgin.net>
More information about the grass-dev