This is the mail archive of the
cygwin
mailing list for the Cygwin project.
inetd-like Windows processes with CYGWIN?
- 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>
- Date: Fri, 26 Jul 2013 19:55:42 +0000
- Subject: inetd-like Windows processes with CYGWIN?
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