Hallo, On Mon, 29 Dec 2003 at 16:51 (+0100), Gerald Goebel wrote:
Hier scheint sich genau der Nachteil vom Multithreding bemerkbar zu machen.
Irgendwie hast Du recht.
Meine Vermutung ist, der Befehl fork in Perl startet nicht einen eigenen Prozess, sondern macht nur einen eigenen Tread im Interpreter dafür auf. Neben dem Verhalten sprechen noch einige andere Aussagen dafür:
Laut Dokumentation (perldoc -f fork): fork Does a fork(2) system call to create a new process running the same program at the same point. It returns the child pid to the parent process, 0 to the child process, or "undef" if the fork is unsuccessful. File descriptors (and sometimes locks on those descriptors) are shared, while everything else is copied. On most systems sup- porting fork(), great care has gone into making it extremely efficient (for example, using copy-on- write technology on data pages), making it the dominant paradigm for multitasking over the last few decades. Also ganz klar ein echter fork().
Bernhard Walle wrote:
On Mon, 29 Dec 2003 at 01:37 (+0100), Ferdinand Ihringer wrote:
Geht Forken eigentlich auch unter Windows? Das müsste ja eigentlich wie kill oder waitpid Unixspezifisch sein. In Perl ja. Als System call existiert es aber nicht.
Note that the issues discussed here are not applicable to platforms where a real fork() is available _and Perl has been configured to use it._
Klingt nach konfigurierbar, stimmt. ;-)
Diese forkemulation gibt es seit 5.6.1. Vorher galt sie als experimentel. Kann es sein das Perl mitlerweile standardmäsig so kompiliert/configuriert wird, das es auch unter Linux dise emulation nutzt, damit es sich auf Linux und Windows (M$ hat wohl diese emulation gesponsert) gleich verhält?
Ich habe hier SuSE 9.0 und das standardmäßige Perl (das vom Online- Update, da gab's mal was). Folgendes Testskript: ,---- | #!/usr/bin/perl | | $pid = fork(); | | if ($pid > 0) # child | { | print "I'm the child!\n"; | sleep 20; | } | elsif ($pid == 0) | { | print "I'm the parent!\n"; | sleep 20; | } | else | { | print "Could not fork: $!"; | } | | print "We do that both!\n"; `---- [~] $ perl test.pl I'm the parent! I'm the child! Auf 'ner anderen Konsole: [~] $ ps aux | grep test.pl | grep perl bwalle 12816 0.0 0.2 3584 1420 pts/3 S 17:16 0:00 perl test.pl bwalle 12817 0.0 0.2 3584 1420 pts/3 S 17:16 0:00 perl test.pl [~] $ kill -SEGV 12817 [~] $ ps aux | grep test.pl | grep perl bwalle 12816 0.1 0.2 3584 1420 pts/3 S 17:16 0:00 perl test.pl Hier also ein ganz klares fork, aber das komische ist dass es hier der Elternprozess auch nicht stibt. Ok, es ist kein echter Speicherzugriffs- fehler. Aber irgendwie ist das jetzt eine gute Gelegenheit, mal etwas C ins Spiel zu bringen *Perl-Buch rauskram* *les* *etwas später* Auch hier lebt der Parent eindeutig weiter. Strange. perl -V Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration: Platform: osname=linux, osvers=2.6.0-test3, archname=i586-linux-thread-multi uname='linux g8 2.6.0-test3 #1 smp fri nov 14 00:07:01 utc 2003 i686 i686 i386 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -pipe' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing' ccversion='', gccversion='3.3.1 (SuSE Linux)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags ='' libpth=/lib /usr/lib /usr/local/lib libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.1/i586-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Dec 10 2003 09:22:12 @INC: /usr/lib/perl5/5.8.1/i586-linux-thread-multi /usr/lib/perl5/5.8.1 /usr/lib/perl5/site_perl/5.8.1/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.1/i586-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl . Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ At least Microsoft offers updates to keep your selection of bugs fresh. -- Alan Shutko, hating Corel even more, in asr