[30066] in Perl-Users-Digest
Perl-Users Digest, Issue: 1309 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Feb 25 21:09:43 2008
Date: Mon, 25 Feb 2008 18:09:09 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 25 Feb 2008 Volume: 11 Number: 1309
Today's topics:
Re: ???? <spamtrap@dot-app.org>
File::Find calls "wanted" before calling "preprocess" <not.com@gmail.com>
Re: File::Find calls "wanted" before calling "preproces <glex_no-spam@qwest-spam-no.invalid>
Re: File::Find calls "wanted" before calling "preproces <not.com@gmail.com>
Re: File::Find calls "wanted" before calling "preproces <ben@morrow.me.uk>
Re: File::Find calls "wanted" before calling "preproces (Randal L. Schwartz)
Re: modperl: HTML::Template not working inside handler <ben@morrow.me.uk>
Re: new variable stupidity <ben@morrow.me.uk>
Re: Processing workload distribution <joost@zeekat.nl>
Re: Processing workload distribution <ben@morrow.me.uk>
Re: Processing workload distribution <ben@morrow.me.uk>
Re: Processing workload distribution <r.ted.byers@rogers.com>
Re: Processing workload distribution <joost@zeekat.nl>
Re: Processing workload distribution <smallpond@juno.com>
Re: Processing workload distribution <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 25 Feb 2008 17:09:45 -0500
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: ????
Message-Id: <m13argk7rq.fsf@dot-app.org>
Chris Mattern <syscjm@sumire.gwu.edu> writes:
> On 2008-02-11, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> paperdo.bbs@bbs.cs.nthu.edu.tw (paperdo) wrote:
>>>
>>>???n????????spss???p???R?? : 1.???z???p 2.T???w 3.ANOVA 4.???????R 5.?]?????R
>>> 6.???]?l?????????R
>> [...]
>>
>> What did you say?
>>
>> jue
>
> Given that the Subject line included the string "big5", I'd have to ask
> if you can speak Chinese.
And given the gibberish quoted, I'd have to ask if his newsreader can
speak big5. :-)
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Mon, 25 Feb 2008 13:12:38 -0800 (PST)
From: yary <not.com@gmail.com>
Subject: File::Find calls "wanted" before calling "preprocess"
Message-Id: <2ac00bee-7b78-486f-9837-5ef142cfc759@i12g2000prf.googlegroups.com>
File::Find always calls "wanted" with "." before calling preprocess
for the first directory. I can work around it, but it doesn't seem
right: the docs say "Your preprocessing function is called after
readdir(), but before the loop that calls the wanted() function."
Or is there a subtle reason why find calls "wanted" with ".", before
letting preprocess change the list of entries, which I should be
appreciating?
A simple program illustrating the order of calls-
#!/usr/bin/perl
use File::Find;
sub wanted { print " I found entry $_\n" }
sub pre { print " Entering $File::Find::dir\n"; @_}
sub post {print " leaving $File::Find::dir\n";}
find ({wanted => \&wanted, preprocess => \&pre, postprocess =>
\&post },'.');
__END__
in an empty dir, produces:
I found entry .
Entering .
leaving .
I expected "Entering ." to be the first line. Tried this on different
machines with perl 5.8 and 5.10.0 with the same results.
thanks for any elucidation
-y
------------------------------
Date: Mon, 25 Feb 2008 16:37:07 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: File::Find calls "wanted" before calling "preprocess"
Message-Id: <47c34314$0$508$815e3792@news.qwest.net>
yary wrote:
> File::Find always calls "wanted" with "." before calling preprocess
> for the first directory. I can work around it, but it doesn't seem
> right: the docs say "Your preprocessing function is called after
> readdir(), but before the loop that calls the wanted() function."
>
> Or is there a subtle reason why find calls "wanted" with ".", before
> letting preprocess change the list of entries, which I should be
> appreciating?
>
> A simple program illustrating the order of calls-
>
> #!/usr/bin/perl
> use File::Find;
> sub wanted { print " I found entry $_\n" }
> sub pre { print " Entering $File::Find::dir\n"; @_}
> sub post {print " leaving $File::Find::dir\n";}
> find ({wanted => \&wanted, preprocess => \&pre, postprocess =>
> \&post },'.');
> __END__
>
> in an empty dir, produces:
> I found entry .
> Entering .
> leaving .
>
> I expected "Entering ." to be the first line. Tried this on different
> machines with perl 5.8 and 5.10.0 with the same results.
>
> thanks for any elucidation
>
> -y
You do have access to the source code to see what's going on.
It shows:
...
@filenames = readdir DIR;
closedir(DIR);
@filenames = $pre_process->(@filenames) if $pre_process;
That should make it clear that 'pre_process' can change
@filenames before it does anything with the file names.
------------------------------
Date: Mon, 25 Feb 2008 15:06:01 -0800 (PST)
From: yary <not.com@gmail.com>
Subject: Re: File::Find calls "wanted" before calling "preprocess"
Message-Id: <c9d82334-422b-478e-bbd4-9b45215df016@d4g2000prg.googlegroups.com>
> You do have access to the source code to see what's going on.
>
> It shows:
> ...
> @filenames = readdir DIR;
> closedir(DIR);
> @filenames = $pre_process->(@filenames) if $pre_process;
>
> That should make it clear that 'pre_process' can change
> @filenames before it does anything with the file names.
That part of the source isn't relevant to my question. Thanks for your
attention though. I have looked through the code, and suppose the
question could be re-worded "why does _find_opt call (via _find_dir)
$wanted_callback before calling $pre_process? That contradicts its
documentation for the preprocess argument."
------------------------------
Date: Mon, 25 Feb 2008 23:06:22 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: File::Find calls "wanted" before calling "preprocess"
Message-Id: <e8ub95-fl11.ln1@osiris.mauzo.dyndns.org>
Quoth yary <not.com@gmail.com>:
> File::Find always calls "wanted" with "." before calling preprocess
> for the first directory. I can work around it, but it doesn't seem
> right: the docs say "Your preprocessing function is called after
> readdir(), but before the loop that calls the wanted() function."
In this case '.' is not obtained from readdir, but from the argument
list, so you don't get to preprocess it at all. If you wanted to, you
should have done it first :).
> A simple program illustrating the order of calls-
>
> #!/usr/bin/perl
> use File::Find;
> sub wanted { print " I found entry $_\n" }
> sub pre { print " Entering $File::Find::dir\n"; @_}
> sub post {print " leaving $File::Find::dir\n";}
> find ({wanted => \&wanted, preprocess => \&pre, postprocess =>
> \&post },'.');
> __END__
>
> in an empty dir, produces:
Calls in brackets:
[stat '.'
> I found entry .
[readdir '.']
> Entering .
[wanted for every entry in '.', that is, none]
> leaving .
So preprocess is called between readdir and the 'wanted' loop, as the
docs say.
Ben
------------------------------
Date: Mon, 25 Feb 2008 16:02:22 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: File::Find calls "wanted" before calling "preprocess"
Message-Id: <861w70bn5d.fsf@blue.stonehenge.com>
>>>>> "yary" == yary <not.com@gmail.com> writes:
yary> That part of the source isn't relevant to my question. Thanks for your
yary> attention though. I have looked through the code, and suppose the
yary> question could be re-worded "why does _find_opt call (via _find_dir)
yary> $wanted_callback before calling $pre_process? That contradicts its
yary> documentation for the preprocess argument."
"preprocess"
The value should be a code reference. This code refer-
ence is used to preprocess the current directory. The
name of the currently processed directory is in
$File::Find::dir. Your preprocessing function is called
after "readdir()", but before the loop that calls the
"wanted()" function. It is called with a list of
strings (actually file/directory names) and is expected
to return a list of strings. The code can be used to
sort the file/directory names alphabetically, numeri-
cally, or to filter out directory entries based on
their name alone. When follow or follow_fast are in
effect, "preprocess" is a no-op.
Note. Called *after* readdir(). As noted in another thread,
no call to readdir() is necessary to obtain your ".".
Docs trump your understanding. Time to realign your understanding. :)
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Mon, 25 Feb 2008 23:01:52 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: modperl: HTML::Template not working inside handler
Message-Id: <00ub95-fl11.ln1@osiris.mauzo.dyndns.org>
Quoth gmail@indigorobot.com:
> Hello everyone,
>
> I'm working on coding up a mod_perl handler, but am unable to get
> HTML::Template to output. Below is my current code:
>
> # file:MyHandler.pm
> #------------------------------------------------------------------
> package MyHandler;
>
> #Load some helpful functions
> use strict; #strict tolerance for code
> use warnings; #extra warnings in the log
> use Carp; #verbose logging
> use diagnostics; #more verbose logging
>
> #Loadup some functions for later use
> use HTML::Template;
>
> #Loadup functions involved in being a handler
> use Apache2::RequestRec ();
> use Apache2::RequestIO ();
> use Apache2::Request;
> use Apache2::Const -compile => qw(OK);
>
> #------------------------------------------------------------------
> #
> # Subroutines
> #
>
> sub handler {
> my $hdlr = shift;
> $hdlr->content_type('text/html');
> $hdlr->print("Handler started<br />");
>
> my $template = HTML::Template->new( filename => "/templates/
> main.tmpl");
> $hdlr->print("outputting template...<br />");
> $template->output();
HTML::Template is writing to STDOUT. You need to tell it to write to the
handler; possibly
$template->output(print_to => $hdlr);
?
Ben
------------------------------
Date: Mon, 25 Feb 2008 23:02:42 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: new variable stupidity
Message-Id: <i1ub95-fl11.ln1@osiris.mauzo.dyndns.org>
Quoth matternc@comcast.net:
> On 2008-02-23, Tad J McClellan <tadmc@seesig.invalid> wrote:
> >
> > (my $newvar = $oldvar) =~ s/something/else/;
> >
> I thought that would change $oldvar as well, but it doesn't. Why not?
The return value of (my $newvar = $oldvar) is $newvar, so that's what
gets modified.
Ben
------------------------------
Date: Mon, 25 Feb 2008 22:40:37 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Processing workload distribution
Message-Id: <87d4qku33e.fsf@zeekat.nl>
Ted <r.ted.byers@rogers.com> writes:
>> There is the Perl function named "system", then there are calls that perl
>> makes into the kernel, referred to as system calls. Â They are different
>> but confusingly named. Â Is your concern about the first or the latter?
>>
> I assumed the former was just a special case of the latter. I was
> concerned about the former, though, because at present I am merely
> launched child processes using it. But the latter would always
> create a nagging doubt, for when I need to make more interesting
> threads.
System calls, on Unix, are a fairly small set of calls (a couple of
hundred, exact number depending on the OS) that can be made from the
program into the kernel. Those system calls basically define the minimum
functionality that programs may need to interact with the OS (and via
the os, with each other).
In addition, there are library functions for C language programs, a lot
of which are built on top of the system calls.
For example, fork(), wait() and exec() are always (well, probably
always) system calls on Unix, but system() is generally a library call
built on top of fork(), wait() and exec(), just like in general malloc()
is implemented as a library function built on the sbrk() syscall, which
is why perl can be built with different malloc() implementations on most
systems. Programmers not building compilers or other programs that need
to interact with the system on a very low level usually won't care which
is which.
Note that some of perl's built-in functions that interact directly with
the OS are sometimes called "syscalls" or "system calls" but may be
implemented in one of the standard C libraries or the perl binary itself
instead of directly in the OS kernel, and which is which may be
different on different OSs and perl builds.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Mon, 25 Feb 2008 22:44:21 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Processing workload distribution
Message-Id: <5vsb95-fl11.ln1@osiris.mauzo.dyndns.org>
Quoth smallpond <smallpond@juno.com>:
> On Feb 25, 1:07 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > Quoth smallpond <smallp...@juno.com>:
> >
> > > See perlthrtut and check your perl build with: perl -V
> > > Look for a line like:
> >
> > > usethreads=define use5005threads=undef useithreads=define
> > > usemultiplicity=define
> >
> > > I believe that the last part indicates whether perl tries to use
> > > multiple CPUs.
> >
> > Please don't make things up and post them without verifying.
> > Multiplicity indicates whether it is possible to have several perl
> > interpreters in the same process: this is a requirement for ithreads (so
> > any perl with useithreads=define will also have usemultiplicity=define)
> > but is also used without ithreads for e.g. mod_perl. It has *nothing* to
> > do with use of multiple CPUs: this is determined by your OS's thread
> > scheduling policy.
>
> I didn't make it up, I looked at previous postings in this NG where
> someone has ithreads=define and not usemultiplicity.
You made up the bit about it affecting CPU affinity.
> http://groups.google.com/group/comp.lang.perl.misc/browse_frm/thread/
> 8f27b699aff8a37d/18a233467aaa72d8?hl=en&lnk=gst&q=usemultiplicity#
> 18a233467aaa72d8
[URL broken. Has the 'net collectively forgotten about msg-ids and news:
urls?]
From that posting:
| useithreads=define usemultiplicity=
I don't really know why that is; probably because the user didn't
explicitly ask for multiplicity. However, the important bits come later:
| Characteristics of this binary (from libperl):
| Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
| PERL_IMPLICIT_CONTEXT
That list has both USE_ITHREADS and MULTIPLICITY in, so that perl was
built with both, as you can see from
| archname=i386-linux-thread-multi
right at the top.
Ben
------------------------------
Date: Mon, 25 Feb 2008 22:54:28 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Processing workload distribution
Message-Id: <4itb95-fl11.ln1@osiris.mauzo.dyndns.org>
Quoth Ted <r.ted.byers@rogers.com>:
> On Feb 25, 1:51 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> >
[threads->create(sub { system "" }) vs.
async { system "" } vs.
system 1, "" on Win32
]
>
> Are there performance implications for the various forms you suggest,
No. async {...} is just a shortcut for threads->new(sub {...}).
> apart from the obvious that the last just has the overhead of creating
> the needed processes while the others create the same processes within
> threads that carry their own overhead. But I doubt that this overhead
> could be significant when the scripts that are launched take hours to
> complete.
I doubt *anything* you do in Perl will be significant compared with that
:).
> > > Is there a Win64::process, or will Win32::process work on a 64 bit
> > > version of windows using the 64 bit build of perl?
> >
> > I don't know. That is, there isn't a Win64::Process, and I don't know
> > whether Win32::Process works on Win64. That depends on whether the
> > underlying Win32 system calls still work the same way: I suspect they
> > do. There are no Win64 results from CPAN Testers (surprise), which is
> > usually the first place to look. In any case, since there aren't any
> > Win64 ppms, you'd need to compile libwin32 from source. Do you have an
> > appropriate compiler?
>
> Well, I have MS Visual Studio 2003, so I suppose I could build it here
> (with a 64 bit target) and deploy it at the office.
Hmmm... maybe, maybe not. You need to use *exactly* the same compiler;
in particular, using a different version of MSVC from the one perl was
built with causes the msvcrt.dll linking to go haywire. I've no idea
what compiler ActiveState use for Win64: for Win32 they use MSVC 6,
which is compatible with MinGW gcc, but somehow I doubt MSVC 6 has a
64-bit target.
> I have yet to get cygwin to work on a 64 bit machine, so the 64 bit
> machine does not have a native compiler installed.
Oh, no, a cygwin compiler won't do at all. :)
> But wait a minute. On the 64 bit machine, 'ppm list' includes
> libwin32 at the bottom of the list. And, I see in the documentation
> Activestate provided with this build that Win32::process is available,
> along with a long list of other Win32 modules. Mind you, I don't know
> if it works since I just found it mere minutes ago.
D'oh! Of course, libwin32 has always been a standard part of ActivePerl
(that's where it came from in the first place). If it's there I'd expect
ActiveState to have tested it.
Ben
------------------------------
Date: Mon, 25 Feb 2008 15:31:21 -0800 (PST)
From: Ted <r.ted.byers@rogers.com>
Subject: Re: Processing workload distribution
Message-Id: <425ca42e-a485-4145-a310-0972afd49957@e23g2000prf.googlegroups.com>
On Feb 25, 5:54=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Ted <r.ted.by...@rogers.com>:> On Feb 25, 1:51=A0pm, Ben Morrow <b..=
.@morrow.me.uk> wrote:
> > > > Is there a Win64::process, or will Win32::process work on a 64 bit
> > > > version of windows using the 64 bit build of perl?
>
> > > I don't know. That is, there isn't a Win64::Process, and I don't know
> > > whether Win32::Process works on Win64. That depends on whether the
> > > underlying Win32 system calls still work the same way: I suspect they
> > > do. There are no Win64 results from CPAN Testers (surprise), which is
> > > usually the first place to look. In any case, since there aren't any
> > > Win64 ppms, you'd need to compile libwin32 from source. Do you have an=
> > > appropriate compiler?
>
> > Well, I have MS Visual Studio 2003, so I suppose I could build it here
> > (with a 64 bit target) and deploy it at the office.
>
> Hmmm... maybe, maybe not. You need to use *exactly* the same compiler;
> in particular, using a different version of MSVC from the one perl was
> built with causes the msvcrt.dll linking to go haywire. I've no idea
> what compiler ActiveState use for Win64: for Win32 they use MSVC 6,
> which is compatible with MinGW gcc, but somehow I doubt MSVC 6 has a
> 64-bit target.
>
While I have MSVS6, you could not pay me to install something that
antiquated on my system. Being used to a reasonably standard
compliant C++ compiler, using some that nacient and broken would be
much too painful.
> > I have yet to get cygwin to work on a 64 bit machine, so the 64 bit
> > machine does not have a native compiler installed.
>
> Oh, no, a cygwin compiler won't do at all. :)
>
Why not? Isn't it just another build of gcc, with libraries required
for programs to work on Windows?
> > But wait a minute. =A0On the 64 bit machine, 'ppm list' includes
> > libwin32 at the bottom of the list. =A0And, I see in the documentation
> > Activestate provided with this build that Win32::process is available,
> > along with a long list of other Win32 modules. =A0Mind you, I don't know=
> > if it works since I just found it mere minutes ago.
>
> D'oh! Of course, libwin32 has always been a standard part of ActivePerl
> (that's where it came from in the first place). If it's there I'd expect
> ActiveState to have tested it.
>
Good to know.
Thanks
Ted
------------------------------
Date: Tue, 26 Feb 2008 00:47:24 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Processing workload distribution
Message-Id: <871w70tx83.fsf@zeekat.nl>
Ted <r.ted.byers@rogers.com> writes:
>> Oh, no, a cygwin compiler won't do at all. :)
>>
> Why not? Isn't it just another build of gcc, with libraries required
> for programs to work on Windows?
Cygwin's compiler is fine, if you're building for cygwin perl. If you're
building modules for activeperl you probably do need a VC compiler that
matches the one used by active state.
Another perl version that ships with a (free) compiler suite is
strawberry perl. It's pretty new, but you might get it to work for your
stuff.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Mon, 25 Feb 2008 16:39:30 -0800 (PST)
From: smallpond <smallpond@juno.com>
Subject: Re: Processing workload distribution
Message-Id: <19be2ece-4633-4830-8a9a-dfdaa67af454@c33g2000hsd.googlegroups.com>
On Feb 25, 5:44 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth smallpond <smallp...@juno.com>:
>
>
>
> > On Feb 25, 1:07 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > > Quoth smallpond <smallp...@juno.com>:
>
> > > > See perlthrtut and check your perl build with: perl -V
> > > > Look for a line like:
>
> > > > usethreads=define use5005threads=undef useithreads=define
> > > > usemultiplicity=define
>
> > > > I believe that the last part indicates whether perl tries to use
> > > > multiple CPUs.
>
> > > Please don't make things up and post them without verifying.
> > > Multiplicity indicates whether it is possible to have several perl
> > > interpreters in the same process: this is a requirement for ithreads (so
> > > any perl with useithreads=define will also have usemultiplicity=define)
> > > but is also used without ithreads for e.g. mod_perl. It has *nothing* to
> > > do with use of multiple CPUs: this is determined by your OS's thread
> > > scheduling policy.
>
> > I didn't make it up, I looked at previous postings in this NG where
> > someone has ithreads=define and not usemultiplicity.
>
> You made up the bit about it affecting CPU affinity.
>
> >http://groups.google.com/group/comp.lang.perl.misc/browse_frm/thread/
> > 8f27b699aff8a37d/18a233467aaa72d8?hl=en&lnk=gst&q=usemultiplicity#
> > 18a233467aaa72d8
>
> [URL broken. Has the 'net collectively forgotten about msg-ids and news:
> urls?]
>
> From that posting:
> | useithreads=define usemultiplicity=
>
> I don't really know why that is; probably because the user didn't
> explicitly ask for multiplicity. However, the important bits come later:
>
> | Characteristics of this binary (from libperl):
> | Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
> | PERL_IMPLICIT_CONTEXT
>
> That list has both USE_ITHREADS and MULTIPLICITY in, so that perl was
> built with both, as you can see from
>
> | archname=i386-linux-thread-multi
>
> right at the top.
>
> Ben
The post is about this exact problem and a poster suggests
checking usemultiplicity. I inferred from that that they
were related since I see nothing in the perl documentation.
I find this in README.cygwin:
"Multiplicity is required when embedding Perl in a C program and using
more than one interpreter instance. This works with the Cygwin port."
It says nothing about ithreads. Maybe you made that up?
------------------------------
Date: Tue, 26 Feb 2008 01:37:44 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Processing workload distribution
Message-Id: <847c95-sm41.ln1@osiris.mauzo.dyndns.org>
Quoth smallpond <smallpond@juno.com>:
>
> The post is about this exact problem and a poster suggests
> checking usemultiplicity. I inferred from that that they
> were related since I see nothing in the perl documentation.
Then both the suggestion and your inference were incorrect. This is
understandable, as the documentation is a rather unclear in this area.
> I find this in README.cygwin:
> "Multiplicity is required when embedding Perl in a C program and using
> more than one interpreter instance. This works with the Cygwin port."
>
> It says nothing about ithreads. Maybe you made that up?
No. From perl.h:
#ifdef USE_ITHREADS
# if !defined(MULTIPLICITY)
# define MULTIPLICITY
# endif
#endif
so you can't have USE_ITHREADS without MULTIPLICITY. More obviously,
since multiplicity is what lets you have several Perl interpreters in
one process, and ithreads create a new interpreter for each thread, you
obviously can't have one without the other. And neither has anything to
do with thread scheduling, which, as I said, is entirely under the
control of your OS's thread implementation.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1309
***************************************
