ajeet@perl has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks

I am writing a program which deals with threads, as because i dont have perl interprter which supports thread natively, I used forks.pm module from CPAN.

Now, When i run my program, i get two threads running for my program. But when i remove "use forks", it displays onle one thread. So, what i guess is that forks module create a new thread which take care of all the thread related activities, cleanup etc.

Problem is that, if i send a signal 'SIGUSR1' or 'SIGUSR2' to my program, it is also delivered to the thread, which is created by forks module, which in result terminate my program. Now, what my requirement is, when i send any signal to my program, then it should be catched by all other threads except that forks module thread.

Is there any way through which i can write a handler, which does nothing and override the handler of thread created by perl forks module. My ultimate goal is just to deliver signals to all threads except the thread of forks module...

Thanks in Advance...

Replies are listed 'Best First'.
Re: Signaling in threads
by BrowserUk (Patriarch) on Apr 07, 2010 at 10:31 UTC

    forks is not threading! And despite it's continued billing as a drop in replacement for threads, it behaves and performs completely differently in every way that is critical: signals, memory, IO, scheduling, semaphoring, locking etc. And refering to forking as "threading" just confuses everyone.

    If you can't or won't install a thread-capable build of Perl, then you will have to use fork for your multi-processing needs. So save yourself, and those that follow you, a lot of grief, and learn to use fork, or one of the many good wrappers like: Parallel:ForkManager now. Rather than pretending to use threads via forks which gives none of the benefits of the former, and compounds most of the downsides of both.


    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.
      CODE 1
      #!/usr/bin/perl print "Hello Monks";

      running the above code and grepping the process results in one process

      CODE 2

      #!/usr/bin/perl use forks; print "Hello Monks";

      running the above code and grepping the process results in two process.

      You all are right, it is actually different process not threads. Now in the code 2, smaller process id is of main program and other process id is one when i write "use fork". Now i want to register a handle for 'SIGUSR2' for the process created by "use forks;"

        Sorry, I cannot help you. The forks module does not run on my system.

        My point was that by mentioning "threads" in the title of your question, you are attracting the wrong people to read it.

        If you need help with the forks module, you should mention that module in your title. And not use the term "threading" when you are forking.


        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.
Re: Signaling in threads
by cdarke (Prior) on Apr 07, 2010 at 09:52 UTC
    Signals and threads do not really mix. Signals are process based, and you never know which thread is going to recieve a given signal - it will whichever is currently processing.

      As forks is a Perl module, and as the OP's perl is built without thread support, I don't think there are actually any true threads involved here (despite the fact that the OP calls them threads).

      Note to the OP: if you provide a short snippet that demonstrates the problem, I (and presumably others, too) will be more inclined to look into the issue...