Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I've read up this question about Linux, Can a port be bound when the process has terminated?
Linux appears to clean up after processes exiting, and leaving open sockets. I was wondering if there's any specification about how this works on Windows. Does the OS consistently take care of closing sockets for processes which exit without closing them?

share|improve this question

3 Answers 3

up vote 8 down vote accepted

On both Windows and Unixen, when a process exits the kernel closes all open handles.

Windows NT

Terminating a Process – MSDN

Terminating a process has the following results:

  • [...]
  • Any resources allocated by the process are freed.
  • All kernel objects are closed.
  • [...]

While open handles to kernel objects are closed automatically when a process terminates, the objects themselves exist until all open handles to them are closed. Therefore, an object will remain valid after a process that is using it terminates if another process has an open handle to it.

ExitProcess function – MSDN

Exiting a process causes the following:

  • [...]
  • All of the object handles opened by the process are closed.
  • [...]

Linux

exit(3) – Linux Programmer's Manual (libc functions)

All open stdio(3) streams are flushed and closed.

_exit(2) – Linux Programmer's Manual (kernel syscalls)

The function _exit() terminates the calling process "immediately". Any open file descriptors belonging to the process are closed; any children of the process are inherited by process 1, init, and the process's parent is sent a SIGCHLD signal.


Note that on both operating systems,

  1. Sockets are just one type of file descriptors (fd's) / kernel objects, so the above applies equally to files and sockets.

  2. File descriptions on Unix, as well as object handles kernel objects on Windows, can be owned by multiple processes – they their handles can be inherited by child processes and even passed around using special IPC functions.

  3. A file or socket is only closed when all fd's pointing to it are destroyed.

share|improve this answer
2  
TCP sockets are a special case, because of their TIME_WAIT states. E.g. if you terminate an application listening on a TCP port, you often cannot bind to the same port immediately. –  haimg Jan 6 '12 at 23:07
2  
No. File descriptors and object handles are owned by and accessible to only one process, and are strictly per-process entities. It is the file description and the underlying object that are shared amongst the processes. –  JdeBP Jan 7 '12 at 4:33

On Windows, a socket is a link between a communications endpoint and a process. This is why, when you duplicate a socket, you wind up with two sockets but only one endpoint. This is why you can't pass a socket from one process to another without creating a new socket in the other process.

If the process ceases to exist, its sockets necessarily cease to exist. There is no concept of a socket without a process to hold it. This is why even Windows kernel drivers that wish to create sockets at kernel level must specify a process to own the socket or call the function from a process context that can own the socket. (Or they can manipulate the endpoints directly without using sockets.)

Your question seems to really be not about sockets but about the communication endpoints themselves. A socket has a reference to its communication endpoint. When the socket goes away, the reference count drops. If it hits zero, it will be removed as soon as that is permissible given the requirements of the communication protocol that endpoint is associated with. TCP has a TIME_WAIT state during which the endpoint must be kept around to handle any "leftover" packets.

share|improve this answer

Yes it does. It has been this way sense windows 3.1 95 98 XP (At least I know for sure since XP).

share|improve this answer
1  
No, it hasn't. Since Windows NT version 3. 5, perhaps. But DOS-Windows was a very different animal to Windows NT when it came to sockets; and DOS-Windows 95 differed from DOS-Windows 3.1 significantly, furthermore. Win16 applications were required to call WSACleanup() otherwise leaks happened; and there was a nasty problem in DOS-Windows 9x, documented in MSKB article #156319, with parent processes invalidating sockets passed to their children, caused by DOS-Windows' rather different process exit semantics for sockets. –  JdeBP Jan 7 '12 at 4:26
1  
@JdeBP: What about Windows NT 3. 1 - did it perform automatic cleanup? –  grawity Jan 7 '12 at 13:20
1  
3.1 didn't have sockets in the first place. –  JdeBP Jan 7 '12 at 16:55
    
...Good point, @JdeBP -- I didn't think of that. –  grawity Jan 8 '12 at 0:46
    
@JdeBP Updated answer to correct it. –  Scott Chamberlain Jan 8 '12 at 0:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.