what is the best choose fork or thread?

[sonet]

I have a project must send a lot of file in win2k at the same time.
But what is the best method in win32?
Can the perl build-in function fork work in win32?
Or the perl build-in thread is good solution

 

[anno4000]

I have a project must send a lot of file in win2k at the same time.
But what is the best method in win32?
Can the perl build-in function fork work in win32?
Or the perl build-in thread is good solution

Who knows? Your problem description is too vague for a meaningful
answer.

fork() works on win32, but is implemented in terms of threads. Choose
the one whose interface matches your needs best, the base mechanism will
be the same in any case.

Anno

 

[Martijn Lievaart]

I have a project must send a lot of file in win2k at the same time.
But what is the best method in win32?
Can the perl build-in function fork work in win32?
Or the perl build-in thread is good solution

Besides Anno's answer, be aware that threads have severe limitations. More
to the point, threads and signals don't mix. So if you need timeouts (in
Perl) or any other signal handling, you are pretty much stuck on forking.

Other than that, in general threads are faster than forks. New threads are
created faster and interthread/process communication is generally faster.
However on Windows, forks are implemented as threads (according to Anno)
so the equation may be different on Windows.

Now you say that this is about "a lot of file". Do you mean transfers of
big files? In that case the transfer time is likely to swamp any
difference between threads and forks, as long as the threads/processes
don't need to communicate much.

The best answer may be to try it out.

HTH,
M4

 

[Ben Morrow]

Besides Anno's answer, be aware that threads have severe limitations. More
to the point, threads and signals don't mix. So if you need timeouts (in
Perl) or any other signal handling, you are pretty much stuck on forking.

Other than that, in general threads are faster than forks. New threads are
created faster

Do you have any evidence for this? While it may be true in general, it
is very much *not* true of Perl threads as currently implemented. For
instance, on my machine,

#!/usr/bin/perl

use threads;
use Benchmark qw/cmpthese/;
use POSIX qw/_exit/;

cmpthese -5, {
fork => sub {
my $p = fork;
if ($p) {
waitpid $p, 0;
}
else {
sub {
return;
}->();
_exit 0;
}
},
thread => sub {
async {
return;
}->join;
},
};

__END__

produces

Rate thread fork
thread 47.2/s -- -99%
fork 4451/s 9326% --

, so forking is an order of magnitude faster than threading. Perl
ithreads are basically an implementation of fork(2) in userspace, so
it's not surprising the OS can do it rather better.

and interthread/process communication is generally faster.

This I would also expect to be false of Perl threads atm, but I can't be
bothered to devise a benchmark. Of course, if you are passing around
Perl data structures, it may be much easier to use threads; but even in
this case, I would advise looking at forks.pm instead.

Ben

 

[Yohan N Leder]

I have a project must send a lot of file in win2k at the same time.
But what is the best method in win32?
Can the perl build-in function fork work in win32?
Or the perl build-in thread is good solution

From what I've seen, fork bugs with script in tainted mode under
ActivePerl 5.8.[7|8] for Windows. So, I'm used to go through fork unless
under Windows where I adapt code to go through Win32:rocess.

 

[Yohan N Leder]

I have a project must send a lot of file in win2k at the same time.
But what is the best method in win32?
Can the perl build-in function fork work in win32?
Or the perl build-in thread is good solution

From what I've seen, fork bugs with script in tainted mode under
ActivePerl 5.8.[7|8] for Windows. So, I'm used to go through fork unless
under Windows where I adapt code to go through Win32:rocess.

Also, forget to say, "use threads;" falls in the same bug as fork in the
same case.

 

[Martijn Lievaart]

Do you have any evidence for this? While it may be true in general, it
is very much *not* true of Perl threads as currently implemented. For
instance, on my machine,

Thanks! I was talking in general, I didn't know Perl threads were this
slow.

M4

 

[xhoster]

Besides Anno's answer, be aware that threads have severe limitations.
More to the point, threads and signals don't mix. So if you need timeouts
(in Perl) or any other signal handling, you are pretty much stuck on
forking.

Other than that, in general threads are faster than forks.

Maybe in some languages, but in Perl they generally aren't.

Xho

 

[nalhawash]

thks

Nasser Alhawash

Xho