Hi, Von "Gurusamy Sarathy via RT" <[EMAIL PROTECTED]> (12 Apr 2005 03:26:42 -0000): > On 11 Apr 2005 16:01:06 -0000, Dagobert Michelsen wrote: > ># <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34914 > > [...] > >I am currently working with an embedded version of Perl 5.8.3 and > >5.8.6 on Solaris together with OpenLDAP 2.2.23. > > > >Perl seems to have a race condition which mixes up filehandles > >from other threads. Perl was not compiled with thread support > >(neither 5.005 nor ithreads) as all accesses to the Perl instance > >have been serialized with mutexes. The problem arises when Perl > >issues a close followed by a dup2 onto the closed filehandle and > >another thread (unrelated to the Perl instance) opens the filehandle > >just closed prior to dup2ing to it. The problem has been analyzed > >by Howard Chu from the OpenLDAP team at > > > > http://www.openldap.org/its/index.cgi/Incoming?id=3567;selectid=3567;usearch > >ives=1 > >and he suggested dropping the explicit close as dup2 already > >closes the target fd. > > 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, 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? Best regards -- Dagobert -- Dagobert Michelsen (Leiter IT) Baltic Online Computer GmbH Alter Markt 1-2, 24103 Kiel, +49 431 54003-0 (Fon) -99 (Fax) Flughafenstr. 52c, 22335 Hamburg, +49 40 53299-395 (Fon) -100 (Fax)
