Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Tue, 7 May 2002 12:32:19 -0400 (EDT)
From: David E Euresti <davie AT MIT DOT EDU>
To: <cygwin AT cygwin DOT com>
Subject: Fork problem
Message-ID: <Pine.GSO.4.30L.0205071225510.29541-100000@buzzword-bingo.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello,
	I slapped on some tools on my fork/Select problem and figured out
what was happening.

	If you need a refresher this is that calling socketpair and then
forking and then closing one end of the socket pair on the child doesn't
mean that the handle has been closed.  Basically after a fork you can have
open handles even if you close them.

	Basically when you call fork you create a new process, and inherit
all the handles.  Then fixup after fork calls DuplicateHandle to construct
the sockets.  So when you originally started with two handles for a socket
pair.  Your child process now has four.  (I detected this by using Process
Explorer from sysinternals)

	So my fix was to before calling the fork store away the handles
(using get_osfhandle) then after the fork the child process closes all the
handles using CloseHandle() of course there should be some better way of
doing this.  I don't think that WSASocket and Duplicate handle are
needed in fhandler_socket.  Since the handles are there I think you can
just set them properly.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/