Francois PIETTE wrote:
>> So let's the boss decide, strange that he did not reply so far.
> 
> The boss married his son yesterday :-)

Congratulations!

> 
>> I prefer the test on not GUnitFinalized
> 
> Me too. Because there could be other things and thesting the global
> variable would be OK for all things.

It's done, I updated the repository (V6 and V7) today.

--
Arno



> A comment in the code where the assertion is could explain in more if
> this helps understanding.
> 
> Thanks guy !
> --
> [EMAIL PROTECTED]
> The author of the freeware multi-tier middleware MidWare
> The author of the freeware Internet Component Suite (ICS)
> http://www.overbyte.be
> 
> 
> ----- Original Message -----
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing" <twsocket@elists.org>
> Sent: Sunday, November 16, 2008 3:36 PM
> Subject: Re: [twsocket] GWndHandlerPool is freed before sockets are
> destroyed
> 
> 
>> Olivier Sannier wrote:
>>> Arno Garrels wrote:
>>>> 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?
>>> Well, you are quite right, I just felt it would be "cleaner" to
>>> assert on the very element that would trigger an access violation
>>> two lines below. I thought it would be clearer for users why we
>>> test on GWndHandlerPool rather than testing on GUnitFinalized.
>> 
>> I prefer the test on not GUnitFinalized but I can live with
>> both, I never run into this problem since I close all threads
>> before I terminate the application.
>> So let's the boss decide, strange that he did not reply so far.
>> 
>> --
>> Arno
>> 
>>> 
>>> 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
-- 
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