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

Patrick Doyle wpd@delcomsys.com
Sat Dec 2 19:47:00 GMT 2000

Christopher Faylor wrote:
> Sorry for the delay in responding.
No problem... I haven't had a chance to work on this Friday or today
anyway...  I did start to get worried when nobody responded 37 minutes
after I first posted my message.  Isn't that the way this list is
supposed to work? ;-)

> >The two ideas I have so far are:
> >1) Switch from using anonymous pipes to using named pipes with unique
> >names.  According to the documentation on the MSDN web site, this is how
> >...
> You can't create named pipes on Windows 95, unfortunately.

> >2) Change the thread_pipe to call ReadFile() (reading one byte) instead
> >of PeekNamedPipe() and save the result for the next call to read.  This
> >has the advantage that it would probably work (based on Christopher's
> >comment and my own experimentation with read() vs. select()), but it
> >looks like a heck-of-a-lot of work (read: prone to bugs) to solve such a
> >stupid problem.  Actually, suggestion #1 suffers from this con as well.
> Your analysis is correct, IMO.  I've been mulling this over for a couple
> of years and have never come up with a satisfactory solution.  Even the
> thread method is prone to difficulties.  If you are blocked on a read of
> a pipe, terminating the thread cleanly becomes problematic.
Oh again
Does "problematic" mean "impossible", or just "messy".  If the first,
then I'll forget about this approach.  If the second, then I'll start
thinking about writing some test code to explore how to do this.

Am I correct in my interpretation that this is only a W9x problem?  Does
PeekNamedPipe() do the right thing when the writer closes the pipe on
NT/2K?  If so, then I would be more inclined to bracket a bunch of messy
hack code with:

if (w9x) {

> It's been some time since I mentioned that "I hate Windows 9x."  This seems
> like a good place to bring this up.
Yeah, but it was a significant improvement over Windows 3.1.  For the
first time (when W95 came out), I was able to run Emacs on the same
machine that I ran my word processor and DSP development tools on; and
more recently, I am able to run all of my favorite GNU utilities, thanks
to the magic of CYGWIN.  So far, I haven't seen such a quantum
improvement in W98, W98SE, or W98ME.  Someday I'll probably switch to
NT, but I worry that it won't work on my notebook.  Sigh...

> I would be really happy if someone had a creative solution to this problem.
> It would be nice to fix this in the Cygwin DLL.
I'm still thinking about it.  I'm not sure I'll come up with a
"creative" solution, most likely a hack solution.  

Some other ideas I've had:
What about implementing pipes using the Windows networking stack (i.e.
implement the pipe by creating a socket from localhost to localhost)?

Is there any way for the writer to a pipe to know anything about the
reader of the pipe?  If that is the case, then the writer could send a
(special) signal to the reader when it closed the pipe.  What to do when
somebody dup()'s one end or the other.  Gee, this problem gets uglier
and uglier the more I think about it.

What about using some other IPC mechanism to implement pipes?  It looks
to me that the way fhandler's are implemented, this should be possible. 
Is there a requirement that pipes must work with non-cygwin
applications?  Hmmm... doesn't bash use pipes to implement, er, pipes? 
If so, then I guess a non-cygwin application would expect to be able to
call ReadFile() in order to get at stdin.

Hopefully, somebody who actually knows how to program in Windows will
also start thinking about this.

Gee, I thought I would start with a nice, simple problem for my first
attempt at contributing to Cygwin.  Oh well...


Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

More information about the Cygwin mailing list