Return-Path: <owner-bug-cvs-list@harvey.cyclic.com>
X-Authentication-Warning: harvey.cyclic.com: majordomo set sender to owner-bug-cvs-list@harvey.cyclic.com using -f
From: Martin Dorey <MDorey@Madge.com>
To: bug-cvs@gnu.org
Subject: CVS on win32
Date: Mon, 14 Dec 1998 13:42:02 -0000
Content-Type: text/plain
Sender: owner-bug-cvs-list@cyclic.com
Precedence: bulk


I was just looking at www.cyclic.com for the first time in a while, to see
if we ought to upgrade cvs 1.9 to 1.10, when 1.11 might be out etc, and I
came across this, under "portability":

	Here's a tip which opens up various other options (such as writing
or finding a freeware inetd): to pass a socket (not a file descriptor) from
	parent to child, mark it as inheritable (via "win32 magic"), and
then pass the number to the child (for example, via an environment variable
or
	command line argument). Rumor has it that the inetd which comes with
OS/2 uses this technique (with the socket number as the last
	argument). 

I've some experience with this, if anyone's interested...

On NT, there isn't much of a problem with inheriting socket handles.  The
only real gotcha is that the C runtime will only use non-overlapped handles
as standard i/o handles.  NT socket handles are overlapped by default.  The
other obscure mistake I made was forgetting to make the listening socket
non-inheritable.  One nasty you might notice when playing around in this
area is that you cannot simultaneously read from and write to a
non-overlapped ("synchronous") socket in different threads - the two
operations will block one another.

Windows 95 (et seq, I guess) is more problematical.  Here, you cannot set C
runtime handles to socket handles.  One solution is to create an anonymous
pipe and pump the data from the socket to and from the pipe.  Again, if you
do the read and writing in different threads, you need an overlapped socket
and you need to do overlapped read and write operations (this is easy, and
doesn't require APCs or anything so VMS-like).  This works fine except that
ms-dos "subsystem" programs (including batch files) cannot take their i/o
from an anonymous pipe created by a win32 subsystem process, only from a
console subsystem process (documented in MSDN).  My daemon was win32
subsystem (so it doesn't need a console window) so, on 95, I spawn a helper
console process in an invisible window, which takes the socket handles as
decimal command line arguments and creates the anonymous pipe as described.

--