Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2016-02

Forcibly terminating a thread

3 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Mark Morgan Lloyd

I've got a program here which, under some conditions of testing, ends up with a thread stuck inside a system call (detail: a mainframe emulator, which is still trying to read a damaged punched card when the operator hits the power-off button).

Is there a way of sending an unambiguous system-level kill signal to a thread? KillThread(ThreadID) doesn't appear to be brutal enough, and I'm unsure of the correct way to access pthread_kill().

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Jonas Maebe
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote
Is there a way of sending an unambiguous system-level kill signal to a thread? KillThread(ThreadID) doesn't appear to be brutal enough, and I'm unsure of the correct way to access pthread_kill().

You cannot asynchronously kill threads on Unix platforms with the cthreads unit, and even on platforms where you can, you should never do it. All resources held by that thread will leak, and locks it held will never be unlocked.

KillThread() on Unix calls pthread_cancel(), which indicates to the system libraries (or any other libraries that include support for this) that that as soon as they know it is safe to kill the current thread, they should abort it and call its registered cleanup functions.

Since you are in an emulator, the way to solve this is probably to have your own threads regularly check the "terminated" property of the tthread and if it's set (which you can do by calling thread.terminate "on it" from another thread), to clean up everything and abort.

Jonas

Mark Morgan Lloyd
to Jonas Maebe
Jonas Maebe wrote 9 lines
On 27/02/16 12:40, Mark Morgan Lloyd wrote: > Is there a way of sending an unambiguous system-level kill signal to a > thread? KillThread(ThreadID) doesn't appear to be brutal enough, and I'm > unsure of the correct way to access pthread_kill(). You cannot asynchronously kill threads on Unix platforms with the cthreads unit, and even on platforms where you can, you should never do it. All resources held by that thread will leak, and locks it held will never be unlocked.

Ouch. But as I said, this is specifically at termination, I'd like to shut down in good order so that I can output the number of times each thread's spun and none of them will be reused.

Show quoted text 9 lines
KillThread() on Unix calls pthread_cancel(), which indicates to the system libraries (or any other libraries that include support for this) that that as soon as they know it is safe to kill the current thread, they should abort it and call its registered cleanup functions. Since you are in an emulator, the way to solve this is probably to have your own threads regularly check the "terminated" property of the tthread and if it's set (which you can do by calling thread.terminate "on it" from another thread), to clean up everything and abort.

It's not so much /in/ an emulator as the code /is/ an emulator.

The threads check for various termination conditions every time they spin, but in this test case one of them's gone into a syscall that can't be completed.

Interestingly, this is /exactly/ why a dot was added after the final END in a number of ALGOL dialects: the emulator is for a B5500 and the hardware doesn't have a "no more cards in hopper" signal.

"The first thing that Dijkstra wanted to see was BEGIN END. compiled and executed.

"We apologized for the “.” being required since that was not a part of Algol. The “.” did not bother thought it was a good idea."

And that's obviously why we've got it in Pascal as well.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]