No, you are right on the money, and I just missed the subtle interactions in your code. I'm use to monolithic scripts. ;-)

Your hint with the signals sound interesting. ..........Or perhaps I'm thinking to complex. Do I really need a thread? My scenario is that the user is pressing on a start button. This shall start a function with a lot of work. I want that the user can interrupt this function at any time by pressing the cancel-button

You are right, on the same analytic path, that everyone else has followed.

It took quite awhile to get the thread->kill signal working in the threads module. But even it, has a drawback. The docs state that a thread kill signal will not interrupt some io operations, so if you have a socket open, or some disk write hang, the thread will still not respond to the kill signal.

So it seems you have to be very careful about wrapping things in eval statements, etc.

There is also another problem with reusable threads, is that the memory used remains claimed by Perl, so the mem usage of a thread will be the peak mem of runs.

There is a comprimise. It helps remove polluting code and fixes the memory use problem. Fork off the heavy work code in the threads, in a way that lets you get a pid of the process. Then stuff that pid in a thread local variable. Now, when you send a thread->kill signal to your thread,(or maybe STATE_DIE instead of signals?) in the signal callback, you can do a killfam($pid). You must be aware of the parent pid and all the children spawned, so you need killfam instead of plain kill. Read the signal(7) manpage. You can create your own custom signal.

Or you could stick with your event_state method, and setup timers in your thread, to check for your states( as in my $thread_die variable)

Moving to Gtk2 would be a good move, because the event looping system is much better. In Gtk2, each thread can have it's own GLib event loop.

Imagine, a master loop, controlling many loops in other threads.

I really want to say explicitly thank you

Hey, I was hoping someone would come up with an object layer abstraction on top of threads, and you are doing it. Thank YOU. :-)

But, remember one thing. Threads are only really useful when you need realtime sharing of data BETWEEN threads. If you are interested in just controlling threads, who happily run in their own space, you are better off forking, just to avoid memory gain problems, and possible non-threadsafe modules.

Finally, from the threads perldoc:

Correspondingly, sending a signal to a thread does not disrupt the operation the thread is currently working on: The signal will be acted upon after the current operation has completed. For instance, if the thread is stuck on an I/O call, sending it a signal will not cause the I/O call to be interrupted such that the signal is acted up immediately.

So you cannot throw ANY code into a thread codeblock, and expect signals to work.