kabe@sra-tohoku.co.jp wrote:
Warning: I’m not a resmgr guru.
alain.bonnefoy@icbt.com > sed in <> 3E644B17.3070403@icbt.com> >:
I would expect the close callback to be called when the parent dies,
but for the close_ocb callback to not be closed yet, since the fd has
been dup()ed, and still exists.
exactly, I attached a callback for io_close_dup and this one is called.
From classical UNIX standpoint, the fd isn’t dup’ed
so this seems correct.
Nobody called dup(), including kernel; the fd only has the
fd.link_count++ on fork() (and decreased to 1 when parent died)
That makes sense when all of the information on fds are kept in kernel
space. Under QNX, though, the implementation side of a fd is a resmgr,
so the information that “link count needs to be incremented” needs to
be passed to the resmgr during a fork() (or spawn()). While, technically,
this isn’t actually a dup() call, the handling is quite similar, and I
(and we) tend to (a bit sloppily) refer to them the same way.
Essentially:
dup says that (pid1, fd2) is the same as (pid1, fd1), while a fork()
ends up saying that (pid2, fd1) is the same as (pid1, fd1).
On the resmgr side, we differentiate between “new open” and “new
reference to existing fd (resmgr side, ocb)” and we differentiate
between “close fd” and “final close, link count now 0”.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.