Re: A basic 'worker' threading example.

Nice post. I never used q->end() before, but enqueued an undef for each thread I had spawned. From now on I will go with the end method.

Normally I start the threads before I start putting work on the queue. In this case it won't make much difference unless the list of hosts to ping is very large, or the file read is the other side of a very slow network link. But sometimes the process sourcing the list of work is comparatively slow, so letting the threads get to work sooner can help

Cheers,
R.

Pereant, qui ante nos nostra dixerunt!

Comment on Re: A basic 'worker' threading example. Download Code

Replies are listed 'Best First'.
Re^2: A basic 'worker' threading example. by Preceptor (Deacon) on Dec 29, 2013 at 17:08 UTC
q -> end is something that a newer version of the Thread::Queue library supports - it's why I didn't use it initially either. And worked around it by some sort of fiddle with pending, semaphores or queuing a load of 'exit' codes. As an alternative, I might offer 'thread->kill'. If you override 'SIGTERM' (which is normally an 'unmaskable' interrupt) you can send 'SIGTERM' to your thread to force it to exit.) E.g.: `#add to thread: $SIG{'TERM'} = sub { threads->exit(); }; ## just before the 'join' add: $thr -> kill ( "SIGTERM" );` [download] This isn't a 'real' SIGTERM as PERL can't trap those - but it's a good way of getting a thread to preemptively terminate. (Although, I'd note that _because_ it's not a 'proper' SIGTERM, it also might be delayed until the current function call has finished. I would normally start the threads first, but dislike doing it if it might 'die' on that file open. There are neater ways of doing it, but I thought to err on the side of brevity.	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: A basic 'worker' threading example.
by Preceptor (Deacon) on Dec 29, 2013 at 17:08 UTC

q -> end is something that a newer version of the Thread::Queue library supports - it's why I didn't use it initially either. And worked around it by some sort of fiddle with pending, semaphores or queuing a load of 'exit' codes. As an alternative, I might offer 'thread->kill'. If you override 'SIGTERM' (which is normally an 'unmaskable' interrupt) you can send 'SIGTERM' to your thread to force it to exit.) E.g.:

#add to thread:
$SIG{'TERM'} = sub { threads->exit(); };


## just before the 'join' add:
$thr -> kill ( "SIGTERM" );
[download]

This isn't a 'real' SIGTERM as PERL can't trap those - but it's a good way of getting a thread to preemptively terminate. (Although, I'd note that _because_ it's not a 'proper' SIGTERM, it also might be delayed until the current function call has finished.

I would normally start the threads first, but dislike doing it if it might 'die' on that file open. There are neater ways of doing it, but I thought to err on the side of brevity.

[reply]
[d/l]