Francois Piette wrote:
>> There are some events in WSocket.pas that may be triggered
>> even though csDestroying is in the ComponentState.
>> Shouldn't we check csDestroying before any event is fired?
>> In a multithreading TWSocketServer app. it would help to
>> avoid AV's.
>
> It seems reasonable. But I wonder which event you have problem with. I've
> a lot of multithreaded applications and have not noticed this kind of
> problem.
When I destroy the SimpleThrdSslServer with alot of threads and clients
I can avoid AV's by this code:
function TCustomWSocket.TriggerDataAvailable(Error : Word) : Boolean;
begin
Result := Assigned(FOnDataAvailable) and not (csDestroying in
ComponentState);
if not Result then
Exit;
...
>
>> I would like to suggest a simple new boolean property Pause.
>> If TRUE we would simply Exit from procedure
>> TCustomWSocketServer.TriggerSessionAvailable.
>
> There is already a method named Pause.
> Basically this is to make the component refuse to accept new connections.
It pauses notification, I'm not 100% sure how Resume behaves,
won't it sure fire no queued events?
> Why not simply close the socket ?
>
>> Also Pause should be set to TRUE in the destructor to avoid
>> multithreading-troubles. What do you thing?
>
> csDestroying is probably enough.
>
> --
> [EMAIL PROTECTED]
> http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
