🚀 go-pugleaf

David Wood <david@thermoteknix.co.uk> wrote:
>Hello one and all

[snip]

>Problem:

[snip]

>and put lots or debug trace statements in. I see there a quite a few
>meesages handled after the origonal FD_ACCEPT or FD_READ. So, at the
>begining of the handler, i put in an WSAAsyncSelect to select no more
>messages, but as the documentation points out, there can (and are) still
>messages in the queue to be handled.

I haven't run across this myself but I am reusing someone elses code right now where they have
dealt with this.  Basically what they do is before closing the socket they check to see if there is
any data left in the queue.  If there is you can either wait for it to be sent or clear it.  I'm not sure
exactly how they checked the queue but I'll look to see if I can find the section of code and
email it to you.  The reason they had to do this was for the very reason you have run into.
Maybe somebody else will have a solution where you don't have to check the queue.

In Article <15034265wnr@thermoteknix.co.uk> David Wood  writes:
>Hello one and all

Hi,

[snip]

I think you might find it's a problem in your coding.  And especially 
in the coding of your tcp/ip class.

I have a class library that does much the same thing.  There's a socket
class and which contains and embedded window.  The window has an extra
window long which stores the this pointer.  When you get an fd* message
you pick up the window long, cast it into a socket pointer and then
call the virtual Read or Write call or something.  You have to be super
careful not to call the socket destructor during any of these calls because
clearly that's going to screw you up because you've got to unwind back 
the stack through the windows procedure.

It's really really easy to make mistakes with this when you have lots
of derived classes and virtual function calls.  For what it's worth,
I call closesocket in response to fd reads or fd accepts all the time and
the system doesn't hang.

--E.