headers
Corinna Vinschen | 12 Jun 2006 15:10
Favicon

Re: Open sockets non-overlapped?

On May 19 16:56, Dave Korn wrote:
> On 19 May 2006 16:20, Lev Bishop wrote:
> > It makes it so that cygwin sockets can be passed usefully to windows
> > processes. Eg:
> > $ cmd /c dir > /dev/tcp/localhost/5001
> > However, it's not perfect -- if the windows process just exits, then
> > the connection is reset, not shut down gracefully.  
> 
>   Well, if the windows process just exits, that is exactly what it has done.
> A socket should be shut down gracefully if the app calls shutdown(), and if it
> just calls close() the socket should be reset.  That's what "gracefully"
> means.
> 
> > Playing with
> > SO_LINGER doesn't seem to help here. Only way I can think of to make
> > it work would be to have the cygwin stub that waits for windows
> > processes to exit, to keep a handle on the socket, poll for when the
> > windows process closes the socket (using NtQuerySystemInformation
> > SystemHandleInformation?) and when it does, close down the socket
> > gracefully.
> 
>   It probably shouldn't be made to "work" because that would be altering the
> semantics of sockets. 
>  
> > Anyway, this adds new functionality and doesn't seem to break anything
> > that worked before.
> 
>   What, you've tested /everything/ that worked before?  ;)
> 
> http://cygwin.com/ml/cygwin/2005-03/msg01003.html
(Continue reading)

Permalink | Reply | 13 comments |
headers
Corinna Vinschen | 12 Jun 2006 16:00
Favicon

Re: Addition to the testsuite & cygwin patch

On May  9 18:11, Pierre A. Humblet wrote:
> The main purpose of this patch is to contribute the attached file to
> testsuite/winsup.api. It checks that Cygwin can support a user
> supplied version of malloc.
> However the patch below is required to make it work and to
> support versions of malloc that don't call sbrk.
> 
> Pierre
> 
> 2006-05-09  Pierre Humblet  Pierre.Humblet <at> ieee.org
> 
>    * winsup.api/malloc.c: New file
> 
> 2006-05-09  Pierre Humblet  Pierre.Humblet <at> ieee.org
> 
> * heap.cc (heap_init): Only commit if allocsize is not zero.

I applied this change.  I just renamed malloc.c to user_malloc.c to
have a slightly more self-describing file name.

Thanks,
Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Permalink | Reply | 0 comments |
headers
Lev Bishop | 13 Jun 2006 03:43
Picon

Re: Open sockets non-overlapped?

On 6/12/06, Corinna Vinschen wrote:
>
> I found that using WSASocket(!OVERLAPPED) instead of socket results in
> sshd misbehaviour (scp takes a long time to start copying files, an
> interactive logon doesn't print the prompt until the user presses the
> return key).  I didn't try to debug this, lazy as I am.

Strange. I don't run sshd, but I've been using this patch for a while
now and not noticed any problems. Maybe I'll try installing sshd one
of these days and see if I see those issues you describe.

> Additionally, I'm really curious *why* opening the socket without the
> overlapped attribute should create a socket being more useful to native
> Windows processes than standard, overlapped attributed sockets.  After
> all the only visible difference is that a socket with the overlapped
> attribute set can use overlapped operations, which the non-overlapped
> socket can't.  It does not mean that overlapping I/O is forced on the
> socket.  It's just adding a capability.

It doesn't make it any less useful to native processes _as a socket
handle_ but it does make a difference when the native processes use it
_as a file handle_. As you know, the semantics of WriteFile() et al
change completely depending on whether they get an overlapped handle
or not (eg the LPOVERLAPPED parameter either _must_ be null or _must
not_ be null, on 95/98/Me) . And there seems to be no way to tell
whether a handle you've inherited was opened overlapped or not (short
of using the NT API: NtQueryInformationFile FILE_MODE_INFORMATION) and
no way to reset the mode once the file has been opened. So
applications are effectively forced to assume their GetStdHandle()s'
are non-overlapped.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Lev Bishop | 13 Jun 2006 04:59
Picon

Re: Open sockets non-overlapped?

On 6/12/06, Lev Bishop wrote:
> On 6/12/06, Corinna Vinschen wrote:
> >
> > I found that using WSASocket(!OVERLAPPED) instead of socket results in
> > sshd misbehaviour (scp takes a long time to start copying files, an
> > interactive logon doesn't print the prompt until the user presses the
> > return key).  I didn't try to debug this, lazy as I am.
>
> Strange. I don't run sshd, but I've been using this patch for a while
> now and not noticed any problems. Maybe I'll try installing sshd one
> of these days and see if I see those issues you describe.

Ok. I just did setup sshd, and I do see those issues, or something
similar (pressing the return key doesn't seem to help with the
interactive logon for me). I wonder what sshd does that everything
else i was using doesn't do.

L
Permalink | Reply | 10 comments |
headers
Lev Bishop | 13 Jun 2006 07:32
Picon

Re: Open sockets non-overlapped?

On 6/12/06, Lev Bishop wrote:
>
> Ok. I just did setup sshd, and I do see those issues, or something
> similar (pressing the return key doesn't seem to help with the
> interactive logon for me). I wonder what sshd does that everything
> else i was using doesn't do.

Meh. The misbehaviour doesn't happen under strace, even with a large
strace buffer, doesn't happen under sshd -d (because with -d it
doesn't fork?). If I attach gdb at the point where it is hung, I seem
to get garbage stack traces. Maybe it's in the middle of forking.
Permalink | Reply | 0 comments |
headers
Corinna Vinschen | 13 Jun 2006 10:21
Favicon

Re: Open sockets non-overlapped?

On Jun 12 21:43, Lev Bishop wrote:
> It doesn't make it any less useful to native processes _as a socket
> handle_ but it does make a difference when the native processes use it
> _as a file handle_. As you know, the semantics of WriteFile() et al
> change completely depending on whether they get an overlapped handle
> or not (eg the LPOVERLAPPED parameter either _must_ be null or _must
> not_ be null [...]

Uh, yes, right.  I can see the potential benefit.  Is the behaviour
of ReadFile/WriteFile with overlapping sockets the same?  Did you try
to write a native testcase (not cygwin) to test this and find out
what happens when no Cygwin is involved at all?  This might give us
some interesting clews.

> Hmph. It works for me. Must be some difference in our configurations,
> windows versions, etc. I note that msdn warns that using socket
> handles as file handles is an optional feature and not all providers
> support it. I guess the provider must be both a Winsock provider and
> also a file-system driver in order to make this work. Maybe you have
> some LSPs on your machine or something?

XP SP2 w/ official updates, plus SFU NFS and a bluetooth stack.

Standard AF_INET sockets should usually work, though.  There's nothing
but standard file/socket types involved in this example.  After all,
I'm running `cmd /c dir' on my NTFS home dir and the AF_INET socket
provider is Microsoft's own.  Maybe I'm naive, but I would assume that
this problem would only happen with 3PPs.

Corinna
(Continue reading)

Permalink | Reply | 0 comments |
headers
Corinna Vinschen | 13 Jun 2006 10:32
Favicon

Re: Open sockets non-overlapped?

On Jun 12 22:59, Lev Bishop wrote:
> Ok. I just did setup sshd, and I do see those issues, or something
> similar (pressing the return key doesn't seem to help with the
> interactive logon for me). I wonder what sshd does that everything
> else i was using doesn't do.

Non-blocking sockets?  User context switching?

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Permalink | Reply | 8 comments |
headers
Lev Bishop | 13 Jun 2006 13:11
Picon

Re: Open sockets non-overlapped?

On 6/13/06, Corinna Vinschen wrote:
> On Jun 12 22:59, Lev Bishop wrote:
> > Ok. I just did setup sshd, and I do see those issues, or something
> > similar (pressing the return key doesn't seem to help with the
> > interactive logon for me). I wonder what sshd does that everything
> > else i was using doesn't do.
>
> Non-blocking sockets?  User context switching?

Possibly. But my money right now is on fork()ing.

Lev
Permalink | Reply | 7 comments |
headers
Dave Korn | 13 Jun 2006 13:19
Favicon

RE: Open sockets non-overlapped?

On 13 June 2006 12:12, Lev Bishop wrote:

> On 6/13/06, Corinna Vinschen wrote:
>> On Jun 12 22:59, Lev Bishop wrote:
>>> Ok. I just did setup sshd, and I do see those issues, or something
>>> similar (pressing the return key doesn't seem to help with the
>>> interactive logon for me). I wonder what sshd does that everything
>>> else i was using doesn't do.
>> 
>> Non-blocking sockets?  User context switching?
> 
> Possibly. But my money right now is on fork()ing.
> 
> Lev

  Have either of you tried CYGWIN=tty vs. CYGWIN=notty in testing this?

    cheers,
      DaveK
--

-- 
Can't think of a witty .sigline today....
Permalink | Reply | 1 comment |
headers
Corinna Vinschen | 13 Jun 2006 17:12
Favicon

Re: Open sockets non-overlapped?

On Jun 13 12:19, Dave Korn wrote:
> On 13 June 2006 12:12, Lev Bishop wrote:
> 
> > On 6/13/06, Corinna Vinschen wrote:
> >> On Jun 12 22:59, Lev Bishop wrote:
> >>> Ok. I just did setup sshd, and I do see those issues, or something
> >>> similar (pressing the return key doesn't seem to help with the
> >>> interactive logon for me). I wonder what sshd does that everything
> >>> else i was using doesn't do.
> >> 
> >> Non-blocking sockets?  User context switching?
> > 
> > Possibly. But my money right now is on fork()ing.
> > 
> > Lev
> 
> 
>   Have either of you tried CYGWIN=tty vs. CYGWIN=notty in testing this?

When logging in through sshd, the terminal settings are always tty on
the server side.  I'm logging in from a remote Linux machine, so I
don't even have the choice for the client side.

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
(Continue reading)

Permalink | Reply | 0 comments |

Gmane