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" <[email protected]> > 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
