... function stop_thread cannot execute functions $inter->{THR}->kill('TERM') and $inter->{THR}->join() and hence, the script cannot wait to thread termination. What is wrong?

Technically speaking, the reason that this line:

    $inter->{THR}->kill('SIGTERM');
[download]

doesn't work, is because of what you are doing in this line:

    $inter->{THR} = ref threads->create(sub{$thread->(\$inter->{INT1})
+});
[download]

That is, instead of storing the thread handle into $inter->{THR}, you are storing the return value of ref when applied to that thread handle. And that means you are storing:

$t = async{ sleep 1000 };;

print ref $t;;
threads
[download]

Ie. You are storing the text string 'threads'.

Which means that when you come to try and call the instance method kill(), instead of passing an instance handle you are calling it as a class method, which (with warnings enabled), should have told you:

Usage: $thr->kill('SIG...') at HardThread.pm line 23.
[download]

It doesn't work because it doesn't know which thread to kill.

To avoid that problem, you would need to store the thread handle directly thus:

    $inter->{THR} = threads->create(sub{$thread->(\$inter->{INT1})});
[download]

Which you've probably tried, only to receive the fatal error message:

Invalid value for shared scalar at HardThread.pm line 29.
[download]

The way to avoid that is to use the shared_clone() function exported by threads::shared, to shared the thread object handle, thus:

    $inter->{THR} = shared_clone( threads->create(sub{$thread->(\$inte
+r->{INT1})}) );
[download]

Make that change, and your code will "work".

That deals with the technical issues with your code; however, it doesn't deal with what (IMO) is a more important issue.

That issue is that the design of your module using shared objects and (pseudo-)signals, in conjunction with threads is a fundamentally flawed concept.

The explanation of why is difficult.

• Every method call involves at least 2 context switches.

  Which make for very slow, computationally expensive objects.

• Methods can be called concurrently from different threads, which means you need to add locking and synchronisation to every method.

  That makes the object slower still.

  Makes them complex to write, test and maintain.

• Makes your threads run in 'lock-step'.
  • Thread 1 does some stuff, the calls a method on a shared object. It now has to block to wait for the method to return.
  • A context switch (eventually) occurs,
  • Thread 2, the 'object thread', which has been spinning its heals (polling) waiting for something to do, executes the (usually trivial) method code and returns the value; and goes back to polling.
  • A context switch occurs.
  • Thread 1 gets the return value from the method.

  It completely defeats the primary benefit of using threading; that of allowing the threads to do work simultaneously.

  Where is the benfit of using an 'object thread', if every time the caller thread calls a method, it has to block until the object thread gets swapped in, does it thing and returns the result?

It is quite likely that this explanation will not convince you -- if you have used Java, the above scenario will likely seem like normal operating procedure -- but if what I've said makes sense to you, and you would like a better approach to solving your problem, then you'll need to describe that actual problem, instead of how you are currently trying to tackle it.