[GRASS-dev] Open/close db drivers order

Radim Blazek radim.blazek at gmail.com
Thu Oct 22 03:10:59 PDT 2015


On Thu, Oct 22, 2015 at 4:16 AM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> Radim Blazek wrote:
>
>> I found, that db drivers must be closed in reverse order to the order
>> in which were opened, otherwise it hangs (Linux). I vaguely remember
>> that this was a problem years ago. Is it still an issue, anybody knows
>> more about the problem?
>
> It sounds like an issue with inheriting file descriptors. I.e.:
>
> 1. Opening the first driver causes the main process to get some file
> descriptors for the pipes connecting it to the driver
>
> 2. Opening the second driver will result in the driver inheriting
> copies of those descriptors from the main process.
>
> 3. When the main process closes the write end of the pipe whose read
> end is the first driver's stdin, the first driver won't get EOF on its
> stdin because the second driver still has a copy of the descriptor for
> the write end of the pipe and hasn't closed it (it doesn't even know
> it has it).
>
> If that's what's happening, setting the close-on-exec flag for each
> descriptor should fix it. E.g.
>
>         void close_on_exec(int fd)
>         {
>         #ifndef __MINGW32__
>             int flags = fcntl(fd, F_GETFD);
>             fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
>         #endif
>         }
>
>         close_on_exec(p1[READ]);
>         close_on_exec(p1[WRITE]);
>         close_on_exec(p2[READ]);
>         close_on_exec(p2[WRITE]);
>
> p1[WRITE] is the one which is most likely to matter; that's the one
> which needs to be closed (in all processes) for the child to get EOF
> on stdin.
>
> p1[READ] and p2[WRITE] are closed in the parent after the child has
> been spawned, so they won't be inherited by subsequent child
> processes.

This works, thanks. I have attached the patch also to the issue.

But there may be other file descriptors not related to db drivers. Is
it possible to close all of them in driver process?

Radim


More information about the grass-dev mailing list