X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:content-type
	:content-transfer-encoding:mime-version; q=dns; s=default; b=c8S
	MAXUBsb1BnY+SWG3YKKuaSwZ757JTHPzJjfYGWH70Hk1FKyK1xwNofhGAcBIYnxi
	5l0BQWrPMlljeGpTxg+5prmrh/SKFjk8vXFZkijAx07YOqjsjFjI/v19msF/G4N0
	mSfmN+SML8gYGixhIb9dhTb5ohOvNTNsTGyvXGKg=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:content-type
	:content-transfer-encoding:mime-version; s=default; bh=hDLHJxgrt
	dXznyZY+NvHPQ0WVJc=; b=oynwfC0n3DYBjivbb0Aj3G1I4aR4tm46Nsw7dnsCh
	y4RffhOuB7ir5ieMiU5NJkzrI57IlYX6W4EEufOjEckHVGbMHP1F/3rWkFfrF7eQ
	cHN3WrLj8XEAtIDOvIvWNiUAIIm6Jdn4PN7/sOiZAM9xi9ACPZWdgP8ejtQJUo4q
	ho=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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
X-Spam-SWARE-Status:	No, score=-1.6 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1
X-IronPortListener:	Outbound_SMTP
X-IronPort-Anti-Spam-Filtered:	true
X-IronPort-Anti-Spam-Result:	AgcFAGzT8lGcKEew/2dsb2JhbABbgwaBBb1egRkWdIImAQQSKFEBFRUULxMXAQ4BBBsah26YRoRmm1ePTINObwOOOY9siwaDFIIq
From:	"Lavrentiev, Anton (NIH/NLM/NCBI) [C]" <lavr AT ncbi DOT nlm DOT nih DOT gov>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject:	inetd-like Windows processes with CYGWIN?
Date:	Fri, 26 Jul 2013 19:55:42 +0000
Message-ID:	<5F8AAC04F9616747BC4CC0E803D5907D0C3BE8BE@MLBXv04.nih.gov>
MIME-Version:	1.0
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id r6QJu6bd029773

Hi,

I'm having problems with getting the following setup to work:

I have a CYGWIN process that listens on a socket (TCP port);
upon sensing an incoming connection (via select()), it accepts,
forks, and attaches the connected socket (via dup2()) to
both STDIN and STDOUT of the (still CYGWIN) child, then execve's
a binary, which is a native Windows console app (that is supposed
to read a request from STDIN and write a response to STDOUT).

I see that for the Windows app, STDIN appears empty (as if EOF is
seen immediately), yet writing to STDOUT causes the following
error (I assume it's sort of Windows EPIPE): "The process tried
to write to a nonexistent pipe."

My first question would be, whether the above is supposed to work at all?
(i.e. whether it is "by design" to use such a process mix, because
if I replace the native Windows app with a (different) Cygwin one,
it gets to read STDIN then successfully replies to STDOUT).

Also, I noticed that if I use the following command as "the native
Windows process",

/cygdrive/c/Windows/system32/cmd.exe /C "COPY CON"

I see (the expected) pairs of CMD.EXE/conhost.exe in Windows Task Manager
created per each request (none of CMD.EXEs are exiting as if waiting
for the COPY commands to finish -- which is weird), but when the main
CYGWIN process gets killed, it only clears up "CMD.EXE" leaving a bunch
of "conhost.exe" behind, and they seem to hang around forever (manual
cleanup is required).

Thanks,

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -