Hello!
I’ve been reading about resource managers and a question has come up for
me. In a conventional (monolithic) operating system the kernel is in a
position to clean up certain items, such as open files, after a process
crashes due to something like an invalid memory access. However, in QNX
the kernel is not responsible for maintaining information about open
files. Instead that information is maintained in a separate process. How
does that process know if one of its clients crashes?
Specifically, if I’m building a resource manager and I allocate some
data structures on behalf of a client in my _IO_OPEN handler, what will
become of those resources if the client never sends me a corresponding
_IO_CLOSE message? I can see that in some cases I may want to keep the
data structures allocated even if I don’t hear from the client for a
“long” time. However, I obviously don’t want to keep them allocated
forever if the client simply died.
Peter
Peter C. Chapin wrote:
Hello!
I’ve been reading about resource managers and a question has come up for
me. In a conventional (monolithic) operating system the kernel is in a
position to clean up certain items, such as open files, after a process
crashes due to something like an invalid memory access. However, in QNX
the kernel is not responsible for maintaining information about open
files. Instead that information is maintained in a separate process. How
does that process know if one of its clients crashes?
Specifically, if I’m building a resource manager and I allocate some
data structures on behalf of a client in my _IO_OPEN handler, what will
become of those resources if the client never sends me a corresponding
_IO_CLOSE message? I can see that in some cases I may want to keep the
data structures allocated even if I don’t hear from the client for a
“long” time. However, I obviously don’t want to keep them allocated
forever if the client simply died.
The bottom line is (using QNX6): you will always get an _IO_CLOSE if a
client dies, the process manager guarantees it.
Rennie
I am assuming this is QNX6 you’re working from, although similar (but
different) principles also apply to QNX4.
The actual table of file descriptors is actually maintained by the
kernel. Note that a file descriptor is really a connection made via
ConnectAttach() to a message channel. So, the kernel will clean-up these
connections when a process dies.
A resource manager (when it calls ChannelCreate()) can set a flag to
have the kernel deliver a pulse when an FD is closed. So, as far as the
resource manager is concerned, when a client dies, it will appear that
the client called close() on all of its open descriptors. All this magic
is done by the resource manager framework.
Daryl Low
Peter C. Chapin wrote:
Hello!
I’ve been reading about resource managers and a question has come up for
me. In a conventional (monolithic) operating system the kernel is in a
position to clean up certain items, such as open files, after a process
crashes due to something like an invalid memory access. However, in QNX
the kernel is not responsible for maintaining information about open
files. Instead that information is maintained in a separate process. How
does that process know if one of its clients crashes?
Specifically, if I’m building a resource manager and I allocate some
data structures on behalf of a client in my _IO_OPEN handler, what will
become of those resources if the client never sends me a corresponding
_IO_CLOSE message? I can see that in some cases I may want to keep the
data structures allocated even if I don’t hear from the client for a
“long” time. However, I obviously don’t want to keep them allocated
forever if the client simply died.
Peter