[GRASS-dev] Open/close db drivers order

[Glynn Clements]

Radim Blazek wrote:

> Should it better go to the original program between fork() and execve()
> or into the driver executable?

Ideally, it should be done by whatever creates the descriptor in the
first place.

Doing it when spawning a DBMI driver (whether in the parent or in the
child) only avoids the specific case where the process holding onto
the descriptor is a DBMI driver.

There are other types of child process which might be spawned
(possibly invisibly to GRASS, e.g. an external library spawning a
"helper" process), and the consequences are always the same.

If I was going to add a mechanism for closing all descriptors other
than 0/1/2, it would probably be as an option to G_spawn_ex().

Also, the situation is potentially worse on Windows, as handles can't
be enumerated (and even if they could, process creation is atomic;
there's no way to execute code in the child process prior to the start
of the new program). If CreateProcess() is called with bInheritHandles
set to TRUE (which is required for stdin/stdout/stderr to be
inherited), all inheritable handles are inherited.

> > The only robust solution is for the original program to systematically
> > set the close-on-exec flag on every descriptor *except* those which
> > are meant to be inherited.
> 
> The original program may be using third party libraries which will
> never care of.

For libraries, it's even more important that they set the
close-on-exec flag on "internal" descriptors, because nothing else
can.

Ultimately, you can have one library which creates "internal"
descriptors and another library which spawns "internal" helper
processes, and there's not much that the main program can do about the
interaction between these.

It's generally considered the responsibility of the code creating
descriptors to set the close-on-exec flag, because that's easier (and
safer) than expecting code which spawns child processes to close
descriptors which it knows nothing about.

In this case, the key issue is that the DBMI client library needs to
set the close-on-exec flag on p1[WRITE], as it's important that this
descriptor doesn't get duplicated.

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