--- In IBObjects@yahoogroups.com, "maikwoj" <mw@...> wrote:

>
> Hi,
>
> I'm working on a problem with thread safety and found a comment in
> IBOs sample "Threads" :
>
> //Don't call inherited Destroy to avoid calling RemoveThread. Don't
> laugh, RemoveThread
> //isn't thread save, for two reasons: 1. It does Dec(ThreadCount)
> asynchronous to the
> //main thread instead of InterlockedDecrement(ThreadCount) what
> would be SMP-safe.
> //2. If ThreadCount becomes zero RemoveThread does a
> PostMessage(ThreadWindow, CM_DESTROYWINDOW)
> //to synchronize with the main thread and instruct the ThreadWindow
> to destroy itself.
> //This is very dangerous because it's not unlikely that a new thread
> is started in the
> //meantime (before the appeneded CM_DESTROYWINDOW is picked out of
> the main-thread message queue)
> //that relies on an existing ThreadWindow. Since it's not very
> useful to destroy the
> //ThreadWindow every time the (unsafe) ThreadCount becomes zero and
> also the inherited
> //TThread.Destroy not TObject.Destroy does nothing else that I
> really need, I workaround this
> //problem by just not calling these methods.
>
> I changed my application to not call the destructor and it starts
> collecting handles. Did I something wrong or is there a better solution.
>
> The problem itself is that the IB_Connection. Open method raises a
> floating point exception (invalid floating point operation). Currently
> I guess it has something to do with my implementation. I do not create
> a session object for every thread (wich I will change now). Does
> anybody have an idea if this can cause an exception like that ?
>
> thx
> maik
>

Ooops, I guess I've forgotten

//it's assumed FFishied=true, but can't check because it's private
in TThread

if Handle <> 0 then CloseHandle(Handle);