in reply to Re: Create a separate process with a sub...
in thread Create a separate process with a sub...

# One (of several) things missing from the API as it stands
# is any way to determine if the thread has finished 
# without blocking.

I think that's pretty easy to do with Thread::Exit. 

use threads ();
use threads::shared ();

my %exited : shared;
use Thread::Exit end => sub { $exited{threads->tid} = 1 };

my $thread = threads->new( sub { whatever } );
my $tid = $thread->tid;

while (!$exited{$tid}) {
# do your stuff
}

[download]
Hmmm... maybe I should just add that to Thread::Exit... ;-)

Liz

Update:
I worked a little on it ;-) 

The uploaded file

    Thread-Running-0.01.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/E/EL/ELIZABETH/Thread-Running-0.01.tar.gz
  size: 3963 bytes
   md5: 847d0175b6f5f355c97d20c73dce7311
The POD starts with: 
NAME
       Thread::Running - provide non-blocking check whether threads are running

SYNOPSIS
           use Thread::Running;      # exports running(), exited() and tojoin()
           use Thread::Running qw(running);   # only exports running()
           use Thread::Running ();   # threads class methods only

           my $thread = threads->new( sub { whatever } );
           while (threads->running( $thread )) {
           # do your stuff
           }

           $_->join foreach threads->tojoin;

           until (threads->exited( $tid )) {
           # do your stuff
           }

DESCRIPTION

       This module adds three features to threads that are sorely
       missed by some: you can check whether a thread is running,
       whether it can be joined or whether it has exited without
       waiting for that thread to be finished (non-blocking).
For the impatient: it can also be fetched from my own list of CPAN modules.

Replies are listed 'Best First'.
Re: Re: Re: Create a separate process with a sub...
by BrowserUk (Patriarch) on Aug 15, 2003 at 12:14 UTC

    Neat! It would be nice if it added an is_finished() (or better named?) method to the threads package, but having an effective method of doing it is great.

    One comment on the name. I would probably never have considered using this without being recommended to it as I would have assumed (from the name) that it was designed for use with the old Thread package.

    I realise that using a "threads::" prefix is taboo as all lowercase names are reserved for pragmas, but maybe a "Threads" top level namespace is called for to distinguish between pThreads and iThreads stuff?

    Probably too late for that now. I'll just have to learn to look inside rather than making assumptions:)

    Now if only there was a portable way of making the Suspend/Resume/SetPriority/ thread (Win32 native) APIs available via threads objects. Most of this has analogous beaviour on other OS's, (priority ~= nice etc.), but it's probably a stretch to try and unify the api?

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
    If I understand your problem, I can solve it! Of course, the same can be said for you.
[reply]
[d/l]
      ...an is_finished() (or better named?)...

      I was thinking of calling it "exited", in a new package Thread::Exited.

      ...I realise that using a "threads::" prefix is taboo as all lowercase names are reserved for pragmas, but maybe a "Threads" top level namespace is called for to distinguish between pThreads and iThreads stuff?

      There were a lot of discussions about that about 14 months ago on p5p (shortly before the release of 5.8.0). "Threads::xxx" was also taboo because of upper/lowecase insensitive file systems. It was decided to use "Thread" as the top level namespace for this type of stuff. And yes, there is some overlap: Thread::Signal being one of them.

      To my knowledge, only Thread::Iterator and Thread::RWLock are for the old 5.005 threads implementation. All other Thread:: modules are for the new ithreads implementation. How do I know? I wrote most of them ;-)

      ... stretch to try and unify the api..

      If there would be people to help on the non-Linux and Windows front (as I don't have access and/or don't have any knowledge), I would be willing to have a go at Thread::Priority.

      Liz

[reply]

        Count me in on the Win32 side.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
        If I understand your problem, I can solve it! Of course, the same can be said for you.
[reply]

In Section Seekers of Perl Wisdom