[fpc-devel] question about thread.WaitFor

[Martin]

Hi,

assuming code like this.
  SomeThread.Terminate;
  SomeThread.WaitFor;

and assuming that SomeThread has at some time before that done
  Thread.Queue(..., SomeHandler)
And the queued item had not run yet.

Is WaitFor guaranteed (or supposed) do have the queued message handled?

I know it waits for thread.Syncronize(), because the thread waits, and
it waits for the thread.
I also checked that 3.0.4 done *not* wait for the queued message (it may
process it, but that is random).

I assume that if the code (in the main thread) wants to be sure, that
SomeHandler (from the queued event) is not called anymore, then it has
to explicitly call CheckSynchronize() ?


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.fre

[Martin]

Post by Martin
assuming code like this.
  SomeThread.Terminate;
  SomeThread.WaitFor;
and assuming that SomeThread has at some time before that done
  Thread.Queue(..., SomeHandler)
And the queued item had not run yet.
Is WaitFor guaranteed (or supposed) do have the queued message handled?

Waitfor wait for thread end. If this is needed to be waited for too,
the logical place would be in whatever
calls .execute.

Agreed, just wanted to check.

Moreover, variables/fields are only destroyed with .free, not with
thread termination, so why does it matter?

If SomeHandler is the method of an object that is about to be destroyed,
then it must be ensured, that it will not be called after (or it will
access the freed object).
I encountered some code, that called only WaitFor. And, as you
confirmed, this is not enough. The message is still on the queue, and
when SomeHandler is called eventually it behaves badly.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/lis

[Martin Frb]

Post by Martin

Moreover, variables/fields are only destroyed with .free, not with
thread termination, so why does it matter?

If SomeHandler is the method of an object that is about to be
destroyed, then it must be ensured, that it will not be called after
(or it will access the freed object).
I encountered some code, that called only WaitFor. And, as you
confirmed, this is not enough. The message is still on the queue, and
when SomeHandler is called eventually it behaves badly.

Actually, its a bit diff.

The queued event gets removed in Thread.Destroy (I had not checked there).
But in the case I was debugging, some objects where left in memory that
relied on the call...

Anyway found what I needed.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list