Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > ithreads at runtime?

Reply
Thread Tools

ithreads at runtime?

 
 
Walter Roberson
Guest
Posts: n/a
 
      02-03-2004
I wonder if someone could give me some hints how to enable
ithread support conditionally at run-time ?


I have written a multi-threaded firewall log analysis program that
calls upon a series of utility modules that I've written. Shared
variables are involved (and Queues, but the Queues don't seem to be a
problem at the moment.) I described some of the effort and lessons in a
previous topic in this newsgroup.

As the program is slower than I'd prefer, I attempted to profile with
-dProf . That failed miserably on any module for which I had
use threads::shared complaining that,

panic: Devel:Prof inconsistent subroutine return at /usr/freeware/lib/perl5/5.8.2/irix-n32-thread-multi/threads/shared.pm line 17.

According to the Devel:Prof documentation, this is a known failure
mode for certain kinds of returns from routines (involving labels.)

I rejigged my modules to do require's instead of use's, and built in
the appropriate run-time logic to know whether to bother to place
lock() and share() calls. In my main code, I placed the appropriate
logic to know to proceed linearily instead of multi-threaded depending
on a run-time option. With appropriate placement of () to delimit
function calls [instead relying on prototypes being available],
and a few other misc. tweaks, I was able to make Devel:Prof happy.
(Looks like massive numbers of split() are my slow point still.)
And in the process I improved the utility modules so they should now
work even without threads configured. A nuisance, but not a wasted effort.

And everything seemed fine until I went to switch back to threaded mode.
When I stopped giving my new run-time option, one of the modules
started complaining that I need to use threads before I
use threads::shared . Some experimentation showed I had to change my
require threads; in my main routine to use threads; instead,
to stop the message... or at least that was the easiest way I could find.
[NB: threads::shared does some magic to force you to include them
in the right order.] But with the 'use' instead of 'require',
Devel:Prof breaks again...


So, at the moment I seem to be stuck. If I use a 'require' then
threads::shared knows that threads weren't invoked at compile time and
shared threads don't work. But if I use a 'use' then Devel:Prof can't
monitor the program.

It's all down to a single statement, but a statement that seemingly
has to go in at compile time rather than at run-time.

Is it fair game to examine @ARGV in a BEGIN block?
Or am I going to have to use some hack such as requiring the
program be invoked via perl -Mthreads to supply the compile-time
context for threads when I want threads used?

Uggh, just realized I could pull a trick such as exec()ing
itself as perl -Mthreads Blech!
--
Those were borogoves and the momerathsoutgrabe completely mimsy.
 
Reply With Quote
 
 
 
 
Ben Morrow
Guest
Posts: n/a
 
      02-03-2004

http://www.velocityreviews.com/forums/(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) wrote:
> I wonder if someone could give me some hints how to enable
> ithread support conditionally at run-time ?

<snip>
> As the program is slower than I'd prefer, I attempted to profile with
> -dProf . That failed miserably on any module for which I had
> use threads::shared complaining that,
>
> panic: Devel:Prof inconsistent subroutine return at
> /usr/freeware/lib/perl5/5.8.2/irix-n32-thread-multi/threads/shared.pm line 17.
>
> According to the Devel:Prof documentation, this is a known failure
> mode for certain kinds of returns from routines (involving labels.)
>
> I rejigged my modules to do require's instead of use's, and built in
> the appropriate run-time logic to know whether to bother to place
> lock() and share() calls.


There's no need to do that. If you 'use threads::shared' without
having a previous 'use threads' those lock and share calls will become
noops.

> And everything seemed fine until I went to switch back to threaded mode.
> When I stopped giving my new run-time option, one of the modules
> started complaining that I need to use threads before I
> use threads::shared . Some experimentation showed I had to change my
> require threads; in my main routine to use threads; instead,
> to stop the message... or at least that was the easiest way I could find.
> [NB: threads::shared does some magic to force you to include them
> in the right order.]


It's not threads::shared magic, it's threads magic. If threads finds
threads::shared has been loaded before it, it complains.

> Is it fair game to examine @ARGV in a BEGIN block?


Err... yes.

BEGIN {
unless (grep $_ eq '-nothreads', @ARGV) {
require threads;
import threads;
}
}

use threads::shared;

or, if you'd rather:

use if not grep($_ eq '-nothreads', @ARGV), 'threads';
use threads::shared;

Get if.pm from CPAN.

Ben

--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces mollit animos, tristesque mentes erigit. | http://www.velocityreviews.com/forums/(E-Mail Removed)
Musica vel ipsas arbores et horridas movet feras. |
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      02-03-2004
In article <bvnnf9$dcm$(E-Mail Removed)>,
Ben Morrow <(E-Mail Removed)> wrote:
:(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) wrote:
:> I wonder if someone could give me some hints how to enable
:> ithread support conditionally at run-time ?

:> I rejigged my modules to do require's instead of use's, and built in
:> the appropriate run-time logic to know whether to bother to place
:> lock() and share() calls.

:There's no need to do that. If you 'use threads::shared' without
:having a previous 'use threads' those lock and share calls will become
:noops.

Thanks, I had forgotten that. I've re-rejigged and that part seems to
working fine.

:> Is it fair game to examine @ARGV in a BEGIN block?

:Err... yes.

Okay, I'll work towards that. I'll have to do a little code restructuring
to make it work right in my situation, but it shouldn't be too bad.
--
Can a statement be self-referential without knowing it?
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      02-04-2004
In article <bvnnf9$dcm$(E-Mail Removed)>,
Ben Morrow <(E-Mail Removed)> wrote:

:(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) wrote:
:> I wonder if someone could give me some hints how to enable
:> ithread support conditionally at run-time ?

r, if you'd rather:

:use if not grep($_ eq '-nothreads', @ARGV), 'threads';

Thanks, I ended up using something akin to that, and now have
a single program that enables or disables thread support at runtime.

It ended up being a lot cleaner than I expected -- when I was written
the program first several weeks ago, the code for supporting or
not supporting threads at need looked like it was going to be excessively
messy.

The bit you reminded me of, of share() and lock() being no-ops
unless use threads is in effect, helps a fair bit.


Another part that helped a fair bit was using share() as a call
instead of using the my $var : shared syntax that doesn't work at all
when threading is not enabled. Using share() as a call also allowed
me to get around some issues that 'my' variables are local to the
block, so you can't define them conditionally -- e.g., you can't have

if ( $Config{useithreads} ) {
my $sharedvar : shared;
} else {
my $sharedvar;
}

because the variable would go out of scope after the 'if'. But this works:

my $sharedvar;
share $sharedvar if $Config{useithreads};
--
Scintillate, scintillate, globule vivific
Fain would I fathom thy nature specific.
Loftily poised on ether capacious
Strongly resembling a gem carbonaceous. -- Anon
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ithreads & memory Micha³ Lesiak (bler) Perl Misc 10 07-21-2005 05:33 PM
ithreads + signals on modern Unices Thomas Jahns Perl Misc 4 02-21-2005 02:25 PM
Qustion about ithreads join Taewoon Kwon Perl 1 09-15-2004 05:55 AM
Knight's tour in perl ithreads Walter Roberson Perl Misc 0 02-02-2004 10:17 PM
Is the ithreads implementation safe? David Morel Perl Misc 0 09-13-2003 06:38 PM



Advertisments