Я могу воссоздать эту проблему на моем WinXP с одинаковыми результатами. Однако, похоже, это влияет только на STDOUT.
Проблема не появляется, если я печатаю в файл, и не появляется, когда я использую STDERR, как предположил Дмитрий. Однако он появляется, если я пишу в STDOUT и в файл. Который является ключом.
Добавление другой переменной обратного ключа в печать приводит к тому, что проблема появляется в двух местах перед каждой конкатенацией.
Во время тестирования я решил, что chomp () недостаточно, и добавил
$str =~ s/[^\w]+//g;
С этим интересным результатом:
[Thread_6] Got string: 'Thread_4Gotstring1925'.
Что, по-видимому, означает, что $str
фактически содержит весь буфер печати из другого потока. Что странно, если не сказать больше.
Если только это ...
Запуск двух потоков в одно и то же время:
print "[Thread_4] Got string: '19'.\n"
$str = `echo 25`
Print и echo, вероятно, совместно используют один и тот же буфер STDOUT, поэтому все это входит в $str
, в результате чего получается:
chomp "[Thread_4] Got string: '19'.\n25\n"
print "[Thread_6] Got string: [Thread_4] Got string: ''19'\n25'.\n"
Короче говоря, проблема с Windows. Если вы хотите «исправить» проблему, убедитесь, что эхо и печать покрыты заблокированными значениями. Перемещение }
в thread_func
ниже _print
должно обеспечить чистую печать. I.e.:
{
lock($run_mut);
my $cmd = _get_cmd($i);
$str = `$cmd`;
chomp $str;
_print "Got string: '$str'.\n";
}
Забавный способ убедиться в этом - заменить echo некоторой командой Windows, которая записывает в STDERR, и посмотреть, не конфликтует ли это с печатью в STDERR в perl.