Re: Why does scp leave ssh running? -- select() never returns

[Patrick Doyle <wpd@delcomsys.com>]

I have been working on a hack workaround for this problem.  (Short
summary -- select() fails to detect when all of the writers of a pipe
have closed the pipe because PeekNamedPipe() on W9x boxen fails to
report when all of the writers of a pipe have closed the pipe.  I am
told that this all works correctly on NT/2K boxen).

Basically, I have modified 'pipe()' to create two windows pipes (on W9x
boxen).  The first pipe is the same one that has always been created. 
The second one is used simply to pass EOF information to the reader of
the (main) pipe.  So, I modified (or rather, created)
fhandler_pipe::close(), which posts an "EOF" message to the 2nd pipe and
I created fhandler_pipe::dup() and fhandler_pipe::fixup_after_fork() to
post a "DUP" message to the 2nd pipe.  Finally, I modified the
processing for select() on an input pipe to check the 2nd pipe, count
the number of DUP and EOF messages, and return "READY" when all of the
writers have closed the pipe.  As I said, it's a hack, but it is one
that only activates on W9x boxen, so it shouldn't be too horrible.

My current problem is, "How do I handle exec()"?  When the new process
is started, I see that handles to both pipes will be inherited by the
exec'd process, but I have no idea how to re-associate the two of them
with each other.  In my search for an answer, I have gotten more and
more confused.  How do fhandlers get recreated for all of the open fd's
in the newly exec'd process?  I see stdio_init(), which creates
fhandlers for fd's 0, 1, and 2, but what about the rest of the open
fd's.  I don't really need an answer to that, but it will keep me
puzzled for weeks.  What I really need an answer to is, "How can an
exec'd process know things about the state of the orignal process,
specifically, what handles were associated with which fhandler objects?"

Am I off on the totally wrong track?  From what I see in spawn.cc, I
think that the exec'd process will start at ground zero, with regard to
the cygwin library.  Somehow information about the fdtab needs to be
communicated to the new process.  I see pointers from the parent process
being passed to the exec'd process via the STARTUPINFO structure, but I
don't see anything like what is in fork.cc, wherein memory regions are
physically copied from one process to the other.  What am I missing. 
(And, BTW, the MSDN documentation for STARTUPINFO says that lpReserved2
must be set to NULL -- you set it to &ciresrv -- how can you get away
with doing something that the MSDN docs say you shouldn't?)

I appreciate any an all pointers that folks would care to give me
regarding this.

TIA

--wpd

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple