unix_hacker_beard has asked for the wisdom of the Perl Monks concerning the following question:

Gracious and Knowledgeable Monks,

I'm dealing with an application with two use cases; a case called "Add" that adds data to a database and a case called "Run" which acts on the database. I want the run instance to be such that when new data is added via "Add", it is enqueued immediately to a thread queue which the main processing loop pulls from.

I have a lock file containing the Run instance's PID and I'm able to signal from Add that new data has been added. However, I wish to defer the operation of catching the signal and enqueueing new data to a thread whose body looks like something of the following: 

sub receive {
   while (1) {
      $SIG{INT} = sub {
         # enqueue new data and stuff
      };
      sleep;
   }
}

[download]

This would add data to a thread queue which the main processing loop would draw from. Is there a way (module) to defer signal handling to a process's thread?

Replies are listed 'Best First'.
Re: Processing a signal in a separate thread
by BrowserUk (Patriarch) on Feb 11, 2011 at 17:10 UTC

    You seem to mixing your terminology. You talk about "the Run instance's PID", and then "it is enqueued immediately to a thread queue which the main processing loop pulls from." Are you using processes or threads? Or a mix of the two?

    When you say "a thread queue", do you mean a Thread::Queue? If so, do you realise that they do not work across process boundaries?

    Basically, you need to explain your set up much more clearly. Preferably by posting working code that demonstrates it.

    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.
[reply]

Back to Seekers of Perl Wisdom