[GRASS5] R_open_driver() after fork()

[Glynn Clements]

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
happen.

> > Presumably the child calls one of the exec*() functions shortly after
> > the fork()? 
> 
> Yes.
> 
> > 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?

> > 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>