I am slowly beginning to understand what you are trying to say. This is my first attempt at threads. I guess when trying to write threads, it requires a change in mentality - breakdown of tasks and split them out into threads. This I think comes with experience. But very nice ideas yours! I think you more than nudged me into threads. Thanks.

Coming back to your post above: Finisher thread was a stupid mistake. I am now rethinking the tasks.

1. Plan is to have a main thread reading the log file.
2. Main thread will also have all encountered MACS to save on lookups if it has already failed earlier.
3. Split the http check part into a thread.
4. Possibly include Auth also in above thread. ( Cant reveal much on this )
5. A separate thread that will monitor all MACs and delete them based on certain conditions based on their network activity

One question : What is the difference between a thread updating a share hash and exiting (A) and a thread joining the main process with return data (B).

In my case where I use a shared hash with MAC keys in the main thread , I feel (A) is a better option. Each thread updates the hash and simply leaves.

What is the difference between a thread updating a share hash and exiting (A) and a thread joining the main process with return data (B).

Um. In generic terms I can only give you a kind of wishy washy answer. The needs of the application.

For some applications you have the need (or opportunity) at some point in the code two parallelise two pieces of code, but then need the results from both before being able to move on to the next part of the problem.

For example, in your scenario above, it may be that the steps 3) http check; and 4) the authorisation; can be run in parallel, but you need the answers from both before you can continue. So

sub checkMAC {
    my $mac = shift;
    my $httpThr = async {
        return head "http://$mac:80"; ## Simplified!!
    };
    my $authResult = get 'http://AuthServer/Check.pl?$mac'; ## Simplif
+ied!!
    my $httpReult = httpThr->join; ## join immediately
    lock %macs;
    $macs{ $mac } = $httpResult && $authResult ? 1 : 0;
}
[download]

But your log reading thread has no interest in the threads it starts, so it can just detach and forget them.

while( <LOG> ) {
    next unless m[ ACK \s+ ( (?: [0-9a-f]{2} : ){5} : [0-9a-f]{2} )]xi
+;
    async( \&checkMAB, $1 )->detach; ## detach cos there's no result w
+e're interested in
}
[download]

Still the bit I am unsure about is your step 5). You say: "monitor all MACs and delete them based on certain conditions based on their network activity"

There is (could be?) a conflict between the two bits I've highlighted. Which I suspect relates back to step 2).

1. What are the conditions that cause a MAC to be deleted?

   Does it depend upon the results of the checks? If so, can't it be done immediately in the checkMAC thread?

   Or is it a function of that individual MACs behaviour over time?

   Or does it depend upon the collective behaviour of two (or more) MACs? Immediately or over time?

2. And where are you deleting it from?

   The clients hash? The network? The Auth server?

3. Is the deletion time critical? Or order critical? Is it high or low priority?

The answer to those questions will govern what is the most appropriate approach to dealing with step 5).

If the deletion needs to be done in a ordered fashion, then it would make sense to have the check threads post a notification via a queue to the deletion thread when they've updated the hash.

But then, if all you are storing in the shared hash is true/false, then it would probably be simpler to dispense with the shared hash completely, and just post the results via the queue:  $Q->enqueue( "$mac:0" )

If it is a function of time or accumulation--(say) delete if it fails 5 times; or fails to respond for 5 minutes--then I would use a prioritised queue.

Or maybe it's just a case of we've heard nothing from that MAC for a while, so let's just free up some resources.

It all comes back to the details behind based on certain conditions based on their network activity?

---

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.

RIP an inspiration; A true Folk's Guy

One question : What is the difference between a thread updating a shared hash and exiting (A) and a thread joining the main process with return data (B).

A couple of thoughts on this.

One of the drawbacks of threads, is that if a thread calls "exit".... it will take down the entire process, all other threads will exit too. I think you mean detach instead of exit.

Secondly, when a thread updates a shared hash, none of the other threads see the update, until they actually try to read it themselves. This is why I like timers so much in the main thread. It can repeatedly loop thru share hashes and update the shared values. As far as I know, there is no tie in shared hashes, that would be a neat feature.

One of the often overlooked aspects of threads, is that in order for a thread to be joined OR detach and dissappear, is that the thread must either

1. reach the end of it's code block or

2. return

So you need to design your threads to finish properly, or they may never join or detach successfully..... they may hang around and give an error like " program exited with 3 threads still running"

---

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh