This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: Winsock closesocket() problem
- From: Jason Tishler <jason at tishler dot net>
- To: "Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>
- Cc: Cygwin-Developers <cygwin-developers at cygwin dot com>
- Date: Thu, 06 Mar 2003 10:40:47 -0500
- Subject: Re: Winsock closesocket() problem
- References: <20030306144658.GB2008@tishler.net> <3E6762CA.8EF5B6A8@ieee.org>
On Thu, Mar 06, 2003 at 10:01:30AM -0500, Pierre A. Humblet wrote:
> Jason Tishler wrote:
> > Note that the problem follows the second close(). If I switch the
> > order of the close() calls, then dup()-ed socket closes without any
> > errors. Hence, I don't believe that this problem is directly
> > related to dup().
>
> and then closing the original socket fails. Correct?
Yes, with the above change I get the following:
$ sc9
close(fd) failed with 108
> last time we talked you indicated that the socket was in fact not
> closed.
Sorry, I meant to get back to you and inform you that the above
conclusion was wrong.
I misinterpreted from where the following Sysinternals' Process
Explorer output came:
0x10 File 0x001F01FF \Device\Afd\Endpoint
0x110 File 0x001F01FF \Device\Afd\Endpoint
The first line above is created *before* socket() is called. The second
one is created by socket() and deleted by the first close(). So, if my
current interpretation is correct, then the socket is indeed being close
albeit possibly too soon.
> Do you know think it is closed but Windows errs in reporting an error?
Yes, I think the socket is closed, but I don't understand why Windows
reports a WSAENOTSOCK error.
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6