Sampo Kellomaki writes:
>Joshua Kronengold wrote:
>> Sampo Kellomaki writes:
>> >I'm a bit new to threaded perl, but I have noticed following
>> >obstacles in writing thread safe code for perl
>> > * file handles can't be made "my"
>> Incorrect. perldoc Filehandle.
>Thanks for pointing me in right way.
You're welcome.
>Now if I could know if the object
>interface is really thread safe or if it in the innards uses local
>variables which are not thread safe.
It's thread safe.
Specifically, its inards use pseudo-randomly genarated symbols that
are guarunteed not to repeat for a rather large set of itterations.
>As you can see, B1 sees the global values. B2 sees local values (because
>f is still sleeping), but F1 sees b's local $a and global $_. This
>is not consistent.
Ok, that's bad. Your example didn't actually prove he problem, but
adding an additional two lines (another sleep 2, another print) to f()
makes it clear that the divergent locals still end up overwriting each
other. The output to my patch of your test code was this, which is
plainly broken:
B1: aaa,ccc
B2: bar,EEE
F1: bar,ccc
F2: foo,DDD
B3: foo,EEE
F3: aaa,DDD
On the other hand, you shouldn't be using local variables
except for magic variables anyway.
>In my opinion $_ behaved correctly while $a
>is broken.
<nod>.
>So from this test I can answer my concerns about map and grep: yes it
>seems $_ has special magical treatment so localization is thread safe.
<nod>. Note that one can semaphore variables via the "Thread.lock"
method. As of 5.05, this is the only way to make sure of your thread
safeness.
In general, look at the perlthrtut proggy for info on how to
make modules thread safe.
>I'd like to know if there is some consistent effort in threaded perl
>to make some classes of constructs thread safe.
Looks like it; this should be documented, though.
>I do not think that would work. It only narrows the window for race
>but does not eliminate it.
<nod> You'd need a Thread.lock() call for that, which kinda sucks.
>BTW, I'm using perl compiled thusly (but the broken behaviour repeats
>under linux-threads as well):
I can confirm that...(here's my version):
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.0.36, archname=i686-linux-thread
uname='linux nassau.mcny.com 2.0.36 #1 tue oct 13 22:17:11 edt 1998 i686 unknown '
hint=recommended, useposix=true, d_sigaction=define
usethreads=define useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O2', gccversion=2.7.2.3
cppflags='-D_REENTRANT -Dbool=char -DHAS_BOOL -I/usr/local/include'
ccflags ='-D_REENTRANT -Dbool=char -DHAS_BOOL -I/usr/local/include'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lpthread -lc -lposix -lcrypt
libc=, so=so, useshrplib=true, libperl=libperl.so
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/lib/perl5/5.00503/i686-linux-thread/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Built under linux
Compiled at Jul 20 1999 11:35:43
@INC:
/usr/lib/perl5/5.00503/i686-linux-thread
/usr/lib/perl5/5.00503
/usr/lib/perl5/site_perl/5.005/i686-linux-thread
/usr/lib/perl5/site_perl/5.005
.
--
Joshua Kronengold ([EMAIL PROTECTED]) |\ _,,,--,,_ ,)
---^---- /,`.-'`' -, ;-;;'
/\\ "What part of 'Pthhhrrrrrrrrrrrrrrrrrr' |,4- ) )-,_ ) /\
-/-\\\-- didn't you understand?" '---''(_/--' (_/-'
