On Tue, 12 Apr 2005 10:35:51 +0200, "Dagobert Michelsen" wrote:
>Von "Gurusamy Sarathy via RT" <[EMAIL PROTECTED]> (12 Apr 2005 03:26:4
>2 -0000):
>> I remember fixing a problem similar to the one you've reported back in
>> 2002. Perhaps the problem code has come back?
>>
>> http://public.activestate.com/cgi-bin/perlbrowse?patch=16331
>>
>> This fix may also be relevant:
>>
>> http://public.activestate.com/cgi-bin/perlbrowse?patch=16333
>
>The code in 5.8.3 looks quite similar to your fix, however it
>only applies if Perl was compiled with threads or ithreads. To
>my understanding it is not necessary to compile Perl with thread
>support if Perl itself is not threaded,
This is not correct. To be completely safe, you need to build
libperl with threads support if you want to run even a single
perl interpreter within a threaded program. Otherwise things
like errno will not work right, since libperl might update a
static copy of errno, while the rest of your program that is
compiled with -D_REENTRANT or similar might do something else,
like indirecting through __errno_location().
Another potential problem is all the foo()/foo_r() functions in
libc and elsewhere that perl links with. I don't think you're
guaranteed to get sane results if the same program calls both
foo() and foo_r() functions from different threads.
Still another problem is mixing malloc()s (either perl's or
libc's) that was built with/without threads support.
There are literally hundreds of other similar cases. It might
be instructive to grep your libc headers for _REENTRANT (or
whatever your libc calls it).
>but is used in a single
>thread as embedded component (this is the scenario I am using).
>Do you see a disadvantage of applying your new code even if
>Perl is not compiled with thread-support? Why did you limit
>your code to a threaded environment?
To be clear, change#16331 wasn't specific to USE_THREADS.
change#16333 was made USE_THREADS specific because it relies
on libc/stdio internals knowledge, and it doesn't make sense
to add that onerous requirement to the vanilla perl binary
(which does not run multi-threaded).
It might be a good idea to add a separate #define for that code
and enable it by default in USE_THREADS mode. People who want
it can then enable it without USE_THREADS. However, if you're
linking libperl into a threaded program and you didn't compile
libperl with threads support, you're probably going to see
other problems (as in the cases above).
If you're not a perl internals whiz to know whether caveats like
the above matter for your application, I highly recommend the
simple and obvious fix: build your perl with -Duseithreads.
Incidentally, I see this in 5.8.6's PerlIOStdio_invalidate_fileno():
#if 0
/* Sarathy's code did this - we fall back to a dup/dup2 hack
(which isn't thread safe) instead
*/
# error "Don't know how to set FILE.fileno on your platform"
#endif
which means that platforms that don't have support in
PerlIOStdio_invalidate_fileno() are silently getting a thread-unsafe
perl when building with -Duseithreads. That seems very broken to me.
How about disabling support for the "stdio" layer on such platforms
when building with -Duseithreads?
Sarathy
[EMAIL PROTECTED]
