This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


On Sat, Dec 02, 2000 at 10:47:44PM -0500, Patrick Doyle wrote:
>> >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.

The problem is that you can terminate a thread using "TerminateThread"
but if the thread is in the middle of doing I/O (i.e. reading from a
pipe) you could leave things in an unstable state.  Microsoft seems to
not want you to use terminate thread:

REMARKS
       TerminateThread  is  used to cause a thread to exit.  When
       this occurs, the target thread has no  chance  to  execute
       any  user-mode  code  and its initial stack is not deallo-
       cated.  DLLs attached to the thread are not notified  that
       the thread is terminating.

       TerminateThread  is  a dangerous function that should only
       be used in the most extreme cases.  You should call Termi-
       nateThread only if you know exactly what the target thread
       is doing, and you control all of the code that the  target
       thread could possibly be running at the time of the termi-
       nation.  For example, TerminateThread can  result  in  the
       following problems:

[more problems deleted]

>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?

Yes.

>> 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)?

I'm sure that that would have its problems too.  I don't like the idea
of using something other than a pipe for a pipe.  For one thing, I think
it will really screw up non-cygwin I/O.

>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.

Cygwin's tty handling has stuff like this.  It is ugly.  It also suffers
from not working with non-cygwin apps.

cgf

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]