in reply to Re^6: killing threads inside forks
in thread killing threads inside forks

Caution: I cannot test this because I don't have a real fork. But ... there are several problems with your code.

  1. You are only setting the signal handler in your threads after your thread function has completed:
    my $t = threads->create (sub{ ## You run your thread function here &$functions_name(@parameters); ## And when it has completed -- if it ever does -- ## You set up a signal handler ... $SIG{KILL} = sub { print "\ngot to thread killer\n\n"; threads->exit(); }; print "\ngot to end of thread\n\n"; #$shutdown = 1; ## and then exit the thread. });
  2. You avoided the kernel wait problem by sleeping until the signal arrives:
    sleep until $shutdown;

    But sleep with no argument is the same as sleep 0; which means that your main thread is thrashing your cpu to death.

    Update: Thanks to rjt for informing me that Perl implements sleep such that: "or forever if no EXPR."; thus my struck assertion above is wrong.

  3. When you do get a signal in your main thread, you then send a kill to all your threads, and then detach them:
    if ($_ != $$){ $_->kill('KILL')->detach; }

    And then you fall through to join them. Except you cannot join a detached thread.

  4. None of what you are doing makes any sense at because (from the threads pod):
    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.
  5. And finally:
    Sending a signal to a terminated thread is ignored.

So, when you say:

this code actually works good when sending USR1 signal

You are wrong. It doesn't "work", it simply breaks your main thread out of the sleep loop. Nothing else.

The signals you think you are sending your threads are never arriving, because you don;t set up their signal handlers until just before they finish. But even if you correct that; those signals still won;t kill the threads -- because kill signals are ignored -- and if you send some other signal, they threads still won't see it until they've finished whatever they are doing.

Which might or might not ever happen; I've no way to tell because you keep posting dummy snippets instead of real code; and have still failed to describe what these threads are actually doing.

I said it earlier, and I'll say it again: signals and threads do not mix.

(The threads-signals stuff should never have been added to the api it is essentially useless!)

If you ever post the real code; and a proper description of what your code is actually doing; I might try to help you further; but for now ....

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.