On Tuesday, June 04, 2013 6:49 PM [GMT+1=CET],
Eric Fleming Bonilha schrob:

> Arno
> 
> In that case, what would happen if I just FREE the socket while it is
> still trying to connect (That case where winsock would still send
> messages). The destructor would call Close, what if in that call
> closesocket() returns WSAEWOULDBLOCK and you reactivate the messages
> and exit from InternalClose and free the socket (While notification
> messages are now reactivated). Woldn´t the same problem happen again?

No, since this is in a repeat-loop (happens very rarely), here V7:

procedure TCustomWSocket.InternalClose(bShut : Boolean; Error : Word);
[..]if FHSocket <> INVALID_SOCKET then begin
        repeat
            { Disable winsock notification otherwise notifications may be }
            { posted even after the call to closesocket()                 }
            WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle, 0, 0); { 
V7.89 }
            { Close the socket }
            iStatus := WSocket_Synchronized_closesocket(FHSocket);
            if iStatus <> 0 then begin
                FLastError := WSocket_Synchronized_WSAGetLastError;
                if FLastError <> WSAEWOULDBLOCK then begin
                    FHSocket := INVALID_SOCKET;
                    { Ignore the error occuring when winsock DLL not      }
                    { initialized (occurs when using TWSocket from a DLL) }
                    if FLastError = WSANOTINITIALISED then
                        break;
                    SocketError('Disconnect (closesocket)');
                    Exit;
                end;
                { Next line is untested, however I think we have to reenable }
                { socket notification here.  (AG)                            }
                WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle,        { 
V7.89 }
                                        FMsg_WM_ASYNCSELECT, FSelectEvent);
                MessagePump;
            end;
        until iStatus = 0;
        FHSocket := INVALID_SOCKET;
    end;

    ChangeState(wsClosed);
    if {$IFNDEF CLR}(not (csDestroying in ComponentState)) and {$ENDIF}
       (not FCloseInvoked) {and Assigned(FOnSessionClosed)} then begin
        FCloseInvoked := TRUE;
        TriggerSessionClosed(Error);
    end;
    { 29/09/98 Protect AssignDefaultValue because SessionClosed event handler }
    { may have destroyed the component.                                       }
    try
        AssignDefaultValue;
    except
    end;
end;  





-- 
Arno
   


> 
> Eric
> 
> -----Mensagem original-----
> De: TWSocket [mailto:twsocket-boun...@lists.elists.org] Em nome de
> Arno Garrels
> Enviada em: terça-feira, 4 de junho de 2013 12:41
> Para: ICS support mailing
> Assunto: Re: [twsocket] Shared handles problem (fixed)
> 
> On Tuesday, June 04, 2013 8:11 AM [GMT+1=CET], Merijn Bosma schrob:
> 
>> Thanks for the quick fix Arno!
>> Did Francois agree with the solution found by Eric?
> 
> I don't know. But turning off winsock notification right before the
> call to closesocket() should be safe. The current fix additionally
> reenables notification messages if the call to closesocket() failed
> with error WSAEWOULDBLOCK before the MessagePump is called.
> 
> --
> Arno
> 
> 
> --
> To unsubscribe or change your settings for TWSocket mailing list
> please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
> Visit our website at http://www.overbyte.be
-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to