Re: hi,something about thread in perl
 

Quoth XiaotingHua <x.t.hua@163.com>:
> i 'd like to write threaded perl program in a IBM machine which contain
> 8 cpu and install AIX 5.1 .
>
> i look at the perlthrtut , and find perl thread is just like the fork in
> unix, which is expensive.

Yup :)

> is perl thread in user-mode or kernel mode? AIX 5.1 support kernel
> thread, and can automatic put the task to all processers.but user thread
> only can do all work in one processer. and if perl thread is only
> running in one processer, it 's senceless for me to do thread program.

Perl threads under unix will use your pthreads (POSIX threads)
implementation, so if your system pthreads library uses kernel threads
(and I'd bet it does, on AIX) then perl will too.

However, as you say, a perl thread is not a thread by any reasonable
definition: it's a userland fork. Without copy-on-write, or any of the
other optimizations the kernel can provide. The ithreads concept
originated in a project to emulate fork on systems which don't support
it, and IMHO on a system which supports fork you'd be *much* better off
with that. You *may* find that if you can create all your threads at
startup that over the course of a long-running program saving the
context switches needed for multiprocess is a significant benefit over
fork, but I doubt it; especially if you aren't forking hundereds of
process but just ~1 per processor.

If you want to use the threads::shared interface while forking, see the
forks module on CPAN.

Ben

--
We do not stop playing because we grow old;
we grow old because we stop playing.
ben@morrow.me.uk

hi,something about thread in perl
 

i 'd like to write threaded perl program in a IBM machine which contain
8 cpu and install AIX 5.1 .

i look at the perlthrtut , and find perl thread is just like the fork in

unix, which is expensive.

is perl thread in user-mode or kernel mode? AIX 5.1 support kernel
thread, and can automatic put the task to all processers.but user thread
only can do all work in one processer. and if perl thread is only
running in one processer, it 's senceless for me to do thread program.

any advise? thank you!

Re: hi,something about thread in perl
 

Ben Morrow wrote:

> Quoth XiaotingHua <x.t.hua@163.com>:
>

> However, as you say, a perl thread is not a thread by any reasonable
> definition: it's a userland fork. Without copy-on-write, or any of the
> other optimizations the kernel can provide. The ithreads concept
> originated in a project to emulate fork on systems which don't support
> it, and IMHO on a system which supports fork you'd be *much* better off
> with that. You *may* find that if you can create all your threads at
> startup that over the course of a long-running program saving the
> context switches needed for multiprocess is a significant benefit over
> fork, but I doubt it; especially if you aren't forking hundereds of
> process but just ~1 per processor.
>
I m more concern the required memory when dealing with million of
processes that created by fork().

Sam.

> If you want to use the threads::shared interface while forking, see the
> forks module on CPAN.
>
> Ben
>

Re: hi,something about thread in perl
 

Quoth sam <sam.wun@authtec.net>:
> Ben Morrow wrote:
>
> > Quoth XiaotingHua <x.t.hua@163.com>:
> >
>
> > However, as you say, a perl thread is not a thread by any reasonable
> > definition: it's a userland fork. Without copy-on-write, or any of the
> > other optimizations the kernel can provide. The ithreads concept
> > originated in a project to emulate fork on systems which don't support
> > it, and IMHO on a system which supports fork you'd be *much* better off
> > with that. You *may* find that if you can create all your threads at
> > startup that over the course of a long-running program saving the
> > context switches needed for multiprocess is a significant benefit over
> > fork, but I doubt it; especially if you aren't forking hundereds of
> > process but just ~1 per processor.
> >
> I m more concern the required memory when dealing with million of
> processes that created by fork().

ithreads copy all perl data structures, without sharing pages. (This is
something that is being worked on, though...) I would expect (though I
haven't checked) a given number of ithreads to use (much) more memory as
well as being slower than a given number of forked processes, again
assuming a vaguely modern Unix OS.

Ben

--
For the last month, a large number of PSNs in the Arpa[Inter-]net have been
reporting symptoms of congestion ... These reports have been accompanied by an
increasing number of user complaints ... As of June,... the Arpanet contained
47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] * ben@morrow.me.uk