Ah, a correction. As noted in Re^2: Perl Threads Boss/Worker Example, the use of detach() is erroneous when you need to join() the thread later. But try a Super Search — there shouldn't be a shortage of Thread::Queue examples.

Thanks for the answer. :) Yes I saw the correction.

I've had a deeper look into perlthrtut meanwhile, too. I think best for me would be a threads->create in combination with detach (since I want a nonblocking behavior for parents's mainloop, where join and also Thread::Queues's dequeue if theres nothing in queue would cause the process to wait, I have tasks that differ a lot in execution time so I want to ensure parent's always in control of what's going on and not "hang" for minutes waiting for child) and share a hash with threads::shared where the thread can report its state and maybe return (simple/non-reference) values to the parent.

Can you confirm that, or is there a better way?

Awww. I just encountered another problem with that. Since these threads are threads and not forks, there are no PIDs, I could use to identify the thread (I would have used that PIDs in the above named shared hash with thread state etc.). Is there some ID for threads? I know I could use the object itself as key in the hash since I can retrieve it in child via threads->self(). But it if should be something, that is not recycled so fast. I mean if the thread is finished I need to depend on no new thread by coincidence gets the same "ID" before the parent gets a chance to check the hash for the status and returns. This should never take longer than lets say worst case a few seconds (more likely ms) so PIDs where a nice ID for that job.

Awww. I just encountered another problem with that. Since these threads are threads and not forks, there are no PIDs, I could use to identify the thread (I would have used that PIDs in the above named shared hash with thread state etc.). Is there some ID for threads? I know I could use the object itself as key in the hash since I can retrieve it in child via threads->self(). But it if should be something, that is not recycled so fast. I mean if the thread is finished I need to depend on no new thread by coincidence gets the same "ID" before the parent gets a chance to check the hash for the status and returns. This should never take longer than lets say worst case a few seconds (more likely ms) so PIDs where a nice ID for that job.