Frage

Ich leite 40-oder-so-Threads mit der folgenden Unterroutine:

my $app = shift;
my $ua = LWP::UserAgent->new();
$ua->timeout(5);
my $response = $ua->get($$app{'watch_url'});
my $new_md5;
if ($response->is_success()) {
    $new_md5 = md5_hex($response->content());
}
return ($$app{'short_name'}, $$app{'watch_md5'}, $new_md5);

Kernmumpen folgen ungefähr 3/4 der Zeit. LWP und LWP :: UserAgent sind reines Perl, also bin ich danach unüberlegt. Ist LWP :: UserAgent nicht thread-sicher?

Aktualisieren:

Hier ist eine minimale Version, um das Problem zu reproduzieren:

use strict;
use warnings;
use threads;
use LWP::UserAgent;

sub check_app {
    my $ua = LWP::UserAgent->new();
    $ua->timeout(5);
    $ua->get('http://www.flatdoc.com/?' . rand(10));
}

my @threads;
for (my $i = 0; $i < 40; $i++) {
    my $thread = threads->create(\&check_app);
    push(@threads, $thread);
}
foreach (@threads) {
    $_->join();
}
War es hilfreich?

Lösung

Nicht-Thread-Safe Pure-Perl-Code verursacht keinen Segfault (in der Tat sollte kein reiner Perl-Code ein Segfault verursachen). Ein Fehler in Perl verursacht einen Segfault. Und Themen in Perl sind historisch sehr fehlerhaft, aber sie sind viel besser geworden.

Ihr Code läuft in 5.10.1 gut und http :: lite kitzelt wahrscheinlich nicht den Perl -Fehler, auf den Sie begegnet sind. Wahrscheinlich müssen Sie nur eine neuere Version von Perl verwenden. Je älter und näher an Redhat Sie erhalten, desto weniger stabile Fäden sind. Wenn Sie Threads verwenden, verwenden Sie die neueste Perl, die Sie in die Hände bekommen können.

Als Alternative zu Threads können Sie so etwas wie verwenden Parallel :: Forkmanager, LWP :: Parallel oder sogar das Erstaunliche Gabeln Modul, das Threads mit Gabel emuliert.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top