Olivier Sannier wrote:
> Arno Garrels wrote:
>> Olivier Sannier wrote:
>>> Assert(Assigned(GWndHandlerPool), 'GWndHandlerPool is already nil,
>>> check your threads!!!'); 
>> I just wonder whether we shouldn't check "not GUnitFinalized" rather
>> than "Assigned(GWndHandlerPool)", what do you think?
> No we should not as it would go against the whole concept of the
> proposed patch.
> The basic idea is that it is quite easy to get the situation where the
> unit is finalized but sockets are still connected and working.
> So the
> patch allows to continue working in this situation without any crash,
> letting either the finalization section or the last socket (whichever
> comes last) to destroy the global handle pool.

Assert(not GUnitFinalized..) would not change this goal, it just would
throw an error (earlier) in cases when a thread tries to create new
sockets even though finalization has been passed and GWndHandlerPool
is not yet nil. I do not understand why you want a thread being able to
create new sockets in this situation?

procedure TForm1.Button1Click(Sender: TObject);
    T : TMyThread;
    T := TMyThread.Create(FALSE);
    T.FreeOnTerminate := True;
    T.FSleep1 := 0;     // create immediately
    T.FSleep2 := 5000;  // wait before destroy

    T := TMyThread.Create(FALSE);
    T.FreeOnTerminate := True;
    T.FSleep1 := 1000; // create delayed
    T.FSleep2 := 0;    // destroy at once


{ TMyThread }

procedure TMyThread.Execute;
  S : TWSocket;
  S := TWSocket.Create(nil);

Set a break point in the finalization section of OverbyteIcsWndControl.pas
in order to hit this case reliable.

Arno Garrels

> However, there is one last case where a socket could still use the
> global handle pool after it has been freed, and this is this case that
> the assert is catching. With the proposed patch, the Assertion can
> only be False if the pool has been freed but a new socket is created
> later on. This can only be because of all sockets being freed, the
> finalization going through but a thread that is still running creates
> a new socket. This new socket will trigger the assertion.
> There is no way to know if such a situation is going to happen, so
> there is no way to get a workaround, hence the need to raise an
> assertion to inform the developer of this issue. The only way to
> detect that situation is because GWndHandlerPool is no longer
> assigned. 
> I hope this clarifies the situation.
> Cheers
> Olivier
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