precision about fork()

Hi,
When a client process dies, the server receives a close msg generated by
the os.

I wrote a test program (a client), which connect to a server, send some
requests and fork.
After fork(), parent dies and child continues.

My server doesn’t receive a close message for the parent session. Is it
because of the file descriptors copy by fork()?

thanks,
Alain.

Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:

Hi,
When a client process dies, the server receives a close msg generated by
the os.

I wrote a test program (a client), which connect to a server, send some
requests and fork.
After fork(), parent dies and child continues.

My server doesn’t receive a close message for the parent session. Is it
because of the file descriptors copy by fork()?

I assume since you are talking about “close” messages, you are talking
about a resource manager framework.

Are you attaching a callback for close or for close_ocb?

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.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs a écrit:

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:


Hi,
When a client process dies, the server receives a close msg generated by
the os.





I wrote a test program (a client), which connect to a server, send some
requests and fork.
After fork(), parent dies and child continues.





My server doesn’t receive a close message for the parent session. Is it
because of the file descriptors copy by fork()?



I assume since you are talking about “close” messages, you are talking
about a resource manager framework.


yes



Are you attaching a callback for close or for close_ocb?


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.

Thanks,
Alain.

-David

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)

Warning: I’m not a resmgr guru.

kabe

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.