Re: Create a separate process with a sub...

[BrowserUk]

Take a look at threads. If you are using AS, then the threads module is locate under the "Pragmas" section of the "Table of Contents" in the left-hand frame of the html docs.

If all you want to do is run the sub standalone to completion, then that is as simple as

use threads;

sub YourSub {
    ...
    return $result;
}

...

my $thread = threads->new( \&YourSub, $arg1, $arg2, ... );

# If your not interested in  the result from the sub then
# $thread->detach;
....
# Otherwise, this will retrieve the return value.
# Note: This will block until the thread finishes.
# One (of several) things missing from the API as it stands
# is any way to determine if the thread has finished 
# without blocking.
my $result = $thread->join;

If you need to communicate between your main code and the subs whilst it is running, then life gets a little more complicated.

If you give a clearer picture of what the sub is going to be doing (like the code:), then it may be possible to give a better example.

---

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.

[Foggy Bottoms]

Thanks again so much BrowserUk, your example is exactly what I needed...
FYI, I'm accessing Outlook and I'm retrieving information. However, ever since Outlook 2000 SP2, a security window pops up : the aim of my thread is to monitor Windows and see whether that window pops up. The thread calls a sub which code is :


sub clearSecurity
{
# As of Outlook 2000 SP2, MS has added a security component that preve
+nts any code
# run from accessing Outlook's inner properties. To impede that techni
+cal protection
# we need to clear the security popup window.
   
   my $securityHandle = 0;
   while (1) # keep on running the test
   {
      sleep(5); # sleep 5 seconds to wait for popup window to come up 
+(should there be one)
      $securityHandle = LTG::dialog::findSecurityWindow();
      LTG::dialog::clearSecurityWindow($securityHandle) if ($securityH
+andle);      
   }
}


What I'm aiming at is to start the sub prior to fiddling with Outlook and kill right after having finished with Outlook...

[bm]

I need to run a thread that'll monitor the hard drive for any file changes

Then maybe Win32::ChangeNotify is also worth a look.
--
bm

[Foggy Bottoms]

I already have the code written (I'm using both changeNotify and advNotify)
I was interested in getting it in a separate thread... But thanks for the comments

[liz]

# 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
}

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.

[BrowserUk]

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.

[liz]

...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