Latest snapshot revamps pipe/fifo handling

[Karl M]

Hi All...

>From: Christopher Faylor Subject: Latest snapshot revamps pipe/fifo 
>handling
>Date: Sat, 7 Jul 2007 13:55:47 -0400
>
>I've checked in a fairly major change to cygwin today.
>
>I yanked out a lot of the win9x specific pipe handling code in the
>latest snapshot and used pure Windows NT (and later) functionality
>instead.  That means that fifos are actually named pipes under the hood
>and both fifos and pipes are using overlapped I/O to allow themselves to
>be interruptible; meaning that the special pipe thread kludge implemented
>for Windows 9x is now gone.
>
>What this means in practice is that pipe handling in snapshots may be a
>little faster.  Pipes and fifos will probably also be a little less
>stable since I'm sure to discover that some of the stuff I yanked out
>probably had meaning even on NT-class systems.
>
>I'll be doing more testing over the weekend but I wanted to give people
>a heads up to expect some potential instability.  If you do detect a
>problem please report it here, along with details.
>
>If you don't have time to report details, need to mention how busy you
>are, need to stress how much you don't know C, want to inform on how
>well it used to work in previous releases, or express puzzlement that it
>works fine on linux, then don't bother sending mail.  Otherwise, I'd
>like to hear about problems.
>
>Reports will include cygcheck output and the exact sequence of steps
>needed to reproduce the problem.  The "exact sequence" will show the
>exact commands or source code which caused the problem and will not be a
>general, vague description of the problem.  The problem will not include
>words like "doesn't work for me" or "crapped out" or "bit the big one"
>but will instead include words like "died with signal N and here is the
>stack trace" or "did not seem to provide any output as you can see from
>this screen capture".

I tried out the July 8, 2007 snapshot cygwin1.dll and had the following 
issue (I replaced just the cygwin1.dll file).

I typed ssh localhost and got as far as the login banner and then it hung 
there. The bash process started by sshd was consuming all avaliable CPU. I 
got the same result if I used ssh to login from another machine. When I 
tried two simultaneous ssh connections, the created bash processes seemed to 
share the CPU equally (by observing them in the taks manager). I use ssh 
agent forwarding in case that is relevant.

The attached cygcheck output is from after I used setup to restore my 
cygwin1.dll. The only change was the cygwin1.dll file.

Thanks,

...Karl
>See http://cygwin.com/problems.html for more details and be sure to read
>more than just the part that says to include cygcheck output.
>
>cgf
>(who is now placing bets)
>
>--
>Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>Problem reports:       http://cygwin.com/problems.html
>Documentation:         http://cygwin.com/docs.html
>FAQ:                   http://cygwin.com/faq/
>

_________________________________________________________________
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygcheck.txt
URL: <http://cygwin.com/pipermail/cygwin/attachments/20070709/3f61ef95/attachment.txt>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/