Re^8: Proposal how to make modules using fork more portable

I would attribute the missing resource cleanup of a pseudo-process-thread to how forked processes are implemented on Windows.

The missing clean-up only happens if the pseudo-process is forceably terminated. And that only becomes a necessary option if the application design assumes that it should be able to interrupt an IO-blocked process with a signal. Which it cannot.

I would hope that an OS cleans up all resources held by a terminated process.

From what I've picked up through osmosis rather than through any practical experience, there are various things that will survive an interrupted process under some or all variants of *nix. File-locks on NFS filesystems; SysV memory, mutexes and semaphores; named pipes. I also vaguely recall something about listening ports (I can't remember if these were unix or inet domain ports) that remained open after the process that created them died until they time out. Typically 15 minutes?

Windows has its own fair share of system resources that can remain in use beyond the process that created them if they are not explicitly cleaned up. Almost any named system object--pipe, semaphore, mutex etc.--will, by design, persist until explicitly closed, or re-boot.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^8: Proposal how to make modules using fork more portable

Replies are listed 'Best First'.
Re^9: Proposal how to make modules using fork more portable by Corion (Patriarch) on Apr 01, 2011 at 22:53 UTC
No, at least named pipes under `\\.\pipe\...` will get removed if the creating process exits. Or rather, the MSDN CreateNamedPipe documentation makes me hope so: An instance of a named pipe is always deleted when the last handle to the instance of the named pipe is closed. Together with the hope that the OS will clean up (and close) all handles created by a process, this means that a pipe should vanish once the creating process exits. But other objects where the creator process is not the permanent owner will have that problem, yes.	[reply] [d/l]
Re^10: Proposal how to make modules using fork more portable by BrowserUk (Patriarch) on Apr 02, 2011 at 12:27 UTC
Together with the hope that the OS will clean up (and close) all handles created by a process, this means that a pipe should vanish once the creating process exits. Under normal operations, a named pipe server will DisconnectNamedPipe() any existing connections prior to exiting. If it doesn't do this because it is killed, then remote clients don't know the server has shut down and so may leave the connection open. Hence the pipe name will still exist in the namespace which can prevent the server restarting. At least that was the explanation given by a vendor for a product failure under NT4 several years ago. Dunno if it was an OS bug since fixed. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]