addmodulefd(..., FDT_INTERNAL or FDT_MODULE);

addmodulefd(..., FDT_INTERNAL or FDT_MODULE);

[Sebastian Gniazdowski]

Hello,
I read whole 36870 topic ("Mangement of fdtable[]") and it's hard to get insight on FDT_INTERNAL vs. FDT_MODULE. I now follow initial db_gdbm.c code which used FDT_INTERNAL. Is it a good choice?

I think both gdbm and redis support cloned file descriptor on fork(), because test cases work fine – database-store in subshell works correctly. This also points that file descriptor isn't closed when using FDT_INTERNAL with addmodulefd().

To note, hiredis (unlike libsqlite3) exposes file descriptor in redisContext::fd field, so it's nice that gdbm and redis behave the same.
--
Sebastian Gniazdowski
psprint /at/ zdharma.org

Re: addmodulefd(..., FDT_INTERNAL or FDT_MODULE);

[Bart Schaefer]

On Jun 14,  7:12am, Sebastian Gniazdowski wrote:
}
} I read whole 36870 topic ("Mangement of fdtable[]") and it's hard
} to get insight on FDT_INTERNAL vs. FDT_MODULE. I now follow initial
} db_gdbm.c code which used FDT_INTERNAL. Is it a good choice?

FDT_MODULE means two things:
(1) The user can't "accidentally" close the descriptor with {fd}>&-
(2) The shell will NOT close the descriptor upon exec(), so it is
    left available for use by external child processes

} I think both gdbm and redis support cloned file descriptor on fork(),
} because test cases work fine - database-store in subshell works
} correctly. This also points that file descriptor isn't closed when
} using FDT_INTERNAL with addmodulefd().

Correct, FDT_INTERNAL descriptors are not closed on fork(), but if the
fork() is followed by an exec() they will be closed.  You can share the
descriptor with a subshell but not with an external command.

So it's up to the module implementor to decide which behavior is the
correct one for his module.