in reply to Dormus interruptus

Just to be difficult... Why are you using multiple threads/processes/whatever? It's hard for me to judge the appropriateness of such a model when you haven't told us what you are doing, but I find that people are excessively prone to using a multi-process/thread model when there are cleaner ways to do it.

If you are monitoring multiple file handles, consider using select. If you are aggregating a bunch of data that is not apt to result in blocking system calls, e.g. waiting for user input, then just suck it all in with one thread serially.

Unless you're doing something as a learning exercise, don't go borrowing trouble. There's plenty of trouble in the world to go around without inventing any of your own. :-)

Replies are listed 'Best First'.
Re^2: Dormus interruptus
by pbeckingham (Parson) on Jun 25, 2004 at 13:11 UTC

    Why thread this? If I were to take a completely linear approach, then it would look something like: 

      while (!$quit)
  {
    gatherData1 ();
    gatherData2 ();
    gatherData3 ();
    renderData ();

    ReadMode 'cbreak';
    $quit = 1 if defined (my $char = ReadKey (0)) && $char eq 'q';
    ReadMode 'normal';
  }

    [download]
    But there are three sets of data here from different sources. There is a dramatic difference in the cost of gathering those three data sets. Data set 1 is gathered from memory, and data set 3 is an expensive, asynchronous query, data set 2 is file I/O. I would like the high refresh rate to see the data that changes often.

    I understand the issues involved with threading, and I don't do this lightly, but I didn't see another way to accomplish this, and get the desired result.

[reply]
[d/l]

In Section Seekers of Perl Wisdom