thread strongly temrinated while waiting for Synchronizeunlock

mauro russo wrote:
what happens when a TThread T object, stopped on
a Synchronize call (having as parameter a TMethod M),
is terminated by the API TerminateThread, executed
in the main thread?

Very bad things. Have you read the documentation for that function? Heed
_all_ the advice you've ever read about TerminateThread: Don't call it.

a) Is the method M executed also if T is already terminated?

T does not terminate. T is just a plain old Delphi object. T was in
possession of an S thread resource, and that thread suddenly popped out
of existence, so T's Handle property is invalid, but there's nothing in
T that knows that.

b) what if the TerminateThread is executed in a different thread, but not the main thread?
Is M executed only if it was already started?

TerminateThread doesn't care what thread it's called from. It's just as
destructive no matter what.

The exact consequences depend on what your program was doing at the time
you called TerminateThread. TThread.Synchronize works in two different
ways depending on your Delphi version.

In older versions, Synchronize calls SendMessage to send a message to a
window owned by the main thread. When the main thread calls a
message-checking function (including GetMessage, PeekMessage, and
SendMessage), the waiting message from Synchronize will be handled. That
entails calling the method pointer included in the message's parameters.

The thread that called SendMessage is blocked waiting for the receive to
grab the message off the queue and finish calling the handler for that
message. If the sender thread disappears, I imagine the message remains
in the message queue, so the main thread will still get notification
that th message is there, and will still handle it. There will just be
no thread left blocking waiting for a response.

In newer Delphi versions, Synchronize puts method pointers into a queue
of their own. It does not use the message queue. It associates an event
with the method, notifies the main thread that the queue is non-empty,
and then blocks on the event.

again, if the waiting thread disappears, the main thread won't know
it. It will still grab the method off the queue and execute it. It will
still signal the event when it's complete. But no one will be left
waiting on that event.

In either case, the main thread may encounter an error when it tries to
determine what method to call. TThread.Synchronize has a TSyncProc
record that it fills with the method pointer and other information for
the main thread. It allocates that record as a local variable, which
means it's on the stack, and then uses a pointer to that variable when
it calls SendMessage or puts the pointer on the method queue. Since
TerminateThread releases the stack memory associated with the S thread,
the main thread is stuck with an invalid pointer when it finally notices
that there's a synchronized method to call.

You will still have an object reference for the TThread object. It
doesn't become nil when the S thread is destroyed. The TThread object
does not call its Terminate event handler, and its Terminated property
is not set to True. Trying to free that object will cause it to try to
terminate the S thread gracefully, but of course that won't work
because there's no thread there to receive the commands TThread's
destructor tries to call.

--
Rob