in reply to Re: Problems using module Async
in thread Problems using module Async

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.

Replies are listed 'Best First'.
Re^3: Problems using module Async
by hfi (Novice) on Nov 29, 2015 at 15:11 UTC

    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?

[reply]

      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.

[reply]
        Is there some ID for threads?

        Yes. It called the thread id: my $thread = threads->create(... ); my $tid = $thread->tid;

        That said, thread handles are also unique, so you could also use that as a key in your hash.

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        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". I knew I was on the right track :)
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
Re^3: Problems using module Async
by hfi (Novice) on Nov 29, 2015 at 17:21 UTC

    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.

[reply]

In Section Seekers of Perl Wisdom