[Guido]
> Are you sure Perl still uses stdio at all?
I've got solid answers now, but I'll paraphrase them anonymously to save the
bother of untangling multi-person email etiquette snarls:
+ Yes, Perl uses platform stdio. Usually. Yes on Windows anyway.
+ But Perl "cheats" on Windows (well, everywhere it can ...), as I've
explained in great detail half a dozen times over the years. No reason to
retract any of that.
+ The cheating is not thread-safe.
+ The last stab at threads accessible from Perl was an experiment that got
dropped. There are no user-muckable threads in std Perl builds.
+ But there is a notion of threads available at the C level.
+ This latter notion of threads is used to implement Perl's fork() on
Windows, so can be exploited to test Windows Perl thread safety without
writing a Perl extension module in C.
+ This Perl program (very much like the 2-threaded one I just posted for
Python) uses that trick:
-------------------------------------------------------------------
sub counter {
my $nc = 0;
while (<FILE>) {
$nc += length;
}
print "num bytes seen = $nc\n";
}
open(FILE, "ga");
binmode FILE;
fork();
&counter();
-------------------------------------------------------------------
Under the covers, that really shares the FILE filehandle on Windows via
threads. Running it multiple times yields multiple wild results; the number
of bytes seen by parent and child rarely sum to the number of bytes actually
in the input file ("ga"). The most common output for me is that one thread
sees the entire file, while the other sees "a lot" of it (since the Perl
inner loop registerizes its FILE* struct member shadows for as long as
possible, that's actually what I expected).
So the code is exactly as thread-unsafe as it looked.
bosses-demand-answers-but-they-forget-their-questions<wink>-ly
y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4