[GRASS5] R_open_driver() after fork()

Radim Blazek blazek at itc.it
Thu Feb 13 09:04:54 EST 2003


Thank you for your prompt help,

On Thursday 13 February 2003 12:08 pm, you wrote:
> Radim Blazek wrote:
> > I have one problem: if module creates child process by fork(),
> > it is impossible open driver by R_open_driver() in parent.
>
> Are you calling R_open_driver() in both parent and child? That would
> explain why the read() call hangs.

No, in parent only.

> > In sync_driver() it hangs on read(). SIGALRM is recieved and dead()
> > executed, but module doesn't continue in execution - still hanging on
> > read(), until child is killed.
>
> The timeout code relies upon signal() having the SysV semantics
> (signals interrupt system calls); it won't work if signal() has the
> BSD semantics (which is the case on Linux with glibc 2.x).
>
> Using sigaction() (without SA_RESTART) works; try the attached patch.
>
> However, I'm unsure as to the portability issues involved. E.g.
> signal() is specified by ANSI (but its semantics aren't well defined),
> while sigaction() is POSIX. OTOH, the new r.mapcalc uses sigaction()
> to catch SIGFPE, and no-one has complained about that yet (but that
> doesn't really say much; we only get regular feedback for Linux and
> MacOSX, and occasional feedback for (specific versions of) Cygwin,
> Irix and Solaris).

No, it did not help, but I was not precise enough in my first mail,
I discovered later that the problem appeares if fork() is executed 
when driver is opened:

R_open_driver();
pid fork(); 
if (pid > 0) {
    R_close_driver();
    R_open_driver();
}

I can avoid this by closing monitor before fork() is called -
but is it final solution?

Thanks

Radim




More information about the grass-dev mailing list