Well, there are even much simpler scenarios when closing file descriptors in kernel can cause harm.
In multithreaded application if one thread opens a file, works with it and then just keeps FD open for some time before 
closing it, the kernel may deallocate that FD on network fault and then other thread may obtain the same FD for other 
file. Now if first thread decides to finally close its file it will close file descriptor of other file allocated from 
other thread.

> In my opinion, the same policy which is used for OCBs at server side should be
>  maintained with file descriptors locally in process (since system is also a 
> kind of server for user mode code). Similarly as server can't close and 
> deallocate OCB on its own will, similarly the system should not close and 
> deallocate FDs if file is not available any more (regardless if the network 
> server died, console terminal destroyed,  or anything else). Instead, the 
> kernel should notify the application with _PULSE_CODE_COIDDEATH, just as it is
>  doing now,  and immediately mark the file descriptor as dead. This way kernel
>  could reject all the requests to the descriptor except for close() with EBADF
>  (or EFAULT) but still keep handle allocated until application cleans up its 
> resources and calls close(). And just after calling close() from application 
> code the kernel may release dead descriptor and reuse it for other files.
> 
> > I need to have open file descriptors to be monitored in my application. For 
> 
> > that I record all the file open calls (I use fd as a key to identify file --
>  
> > what else???) and find file records by fd and clear them before files are 
> > closed.
> > Now I have an assertion failed that open() returned a fd which is already 
> > recorded in the list. As far as I understand, the only possibility for that 
> 
> > could be _PULSE_CODE_COIDDEATH being already queued on dispatch but handler 
> 
> > thread having not yet extracted and handled that pulse (not cleared the file
>  
> > record) while another thread has already received the same fd from next open
> ()
> >  call.
> > Could anyone confirm if that scenario could be possible indeed (QNX 6.3.0 
> SP3)
> >  and in case of positive answer what approach would you suggest to maintain 
> 
> > index of open files by their fds?
> 
>