in reply to Re: Perl threads - telling them urgent stuff
in thread Perl threads - telling them urgent stuff

According to the author of the original post, he has already considered shared variable, and he described the problem with that, so that's not what he asked for.

No, Thread::Signal is not a better option, and it is even not an option. this problem is more difficult than it sounds.

The problem described in the original post is not that he can not receive signal, on the contrary, he can receive signal with no problem. The same problem (the real problem) exists for both threads module and Thread::Signal module. What he really had problem with is how to instrcut the spider thread to stop. Assume he received a signal or anhthing similar, what he should do to stop the spider thread.

If you don't care whether the program stops decently, the thing becomes much easy. If Tk runs on main thread (most likely), just have a button, when the user clicks it, exit. For example:

use Tk;
use IO::Socket::INET;
use threads;
use strict;
use warnings;

$| ++;

threads->create(\&a);

my $mw = MainWindow->new(title => "window");
$mw->Button(text => "exit", command => sub {exit})->pack();
MainLoop;

sub a {
    sleep(10000);
}

[download]

If he wants to quit, he can quit, just whether it is decent enough to the author's standard.

A real problem he might encounter is that the spider thread can take up lots of CPU cycles, and makes the Tk thread not responding. In that case, what he needs is make the spider thread yields (threads module delivers this) periodically, so the Tk thread get a chance to run.

Replies are listed 'Best First'.
Re: Re: Re: Perl threads - telling them urgent stuff
by liz (Monsignor) on Oct 20, 2003 at 08:18 UTC
    ... what he needs is make the spider thread yields (threads module delivers this) periodically...

    I think this is bad advice generally. My experience with yield() is that it just eats CPU, as it is a noop at least on some versions of Linux (I don't know about Windows, as I don't go there anymore).

    Under Linux, each thread has its own pid (although it's pretty tricky to get it: this is basically the only XS functionality needed by Thread::Signal). So you are able to use POSIX::nice on that platform.

    BrowserUK has been looking at setting priority of threads on Windows, but as he has described in several nodes in this thread, the problem is interfacing between what Perl thinks threads are and what the OS thinks threads are.

    In a non-event driven situation, I would probably use a lock(), cond_wait() and cond_signal() combo by which threads tell each other something has happened or needs to be done. But obviously, that is a bit tricky doing from the Tk event loop.

    Liz

[reply]
Re: Re: Re: Perl threads - telling them urgent stuff
by BrowserUk (Patriarch) on Oct 20, 2003 at 00:45 UTC

    Can you explain why Thread::Signal is not an option?

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    Hooray!
[reply]
      Becasue:
      • Its own document said so. With new code, don't expect it to be able to handle signal safely.
      • What's the point to develop some code base on something you expect to become obsolete very soon?
[reply]

        Okay. I think I have found the source of the confusion. There are two packages on CPAn by the same name. The one your looking at is this This one, which is obsolete.

        However, there is also this one which liz wrote quite recently specifically to enable the use of signals and signal handlers across and between threads (for linux and similar systems).

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        Hooray!
[reply]

In Section Seekers of Perl Wisdom