develooper Front page | perl.perl5.porters | Postings from August 2017

Calls in the perl core distribution that are unsafe in multithreaded applications

Thread Next
From:
Karl Williamson
Date:
August 9, 2017 18:09
Subject:
Calls in the perl core distribution that are unsafe in multithreaded applications
Message ID:
f0b93846-1263-fc09-de67-6eaec86b5b70@khwilliamson.com
I looked at the glibc man pages to try to find all functions that we 
call that aren't thread safe, and to see if we properly have taken this 
into account.  This is what I found (though perhaps I missed some 
things, and other systems may have a differing set of functions that are 
unsafe).

Anything that changes the environment is unsafe: we call putenv(), 
clearenv(), and setenv().  I didn't see any synchronization around 
these.  I believe these calls should be changed to be protected by 
semaphores.  I wonder if this is the cause of some unexplained bugs.

Sys::Syslog calls setlogmask(), which has a race if another thread is 
doing the same thing at the same time.  Though unlikely to occur, I 
believe this should have a semaphore as well.

Windows calls fcloseall(), which in glibc has a race with 'streams'.  I 
don't know if it is safe on Windows.

exit() turns out to be unsafe; the only symptom I could find in an 
internet search is the process hanging.  I don't see us making any 
changes here.

sleep() is unsafe, having a conflict with SIGCHILD.  I wonder if this is 
the cause of some of our timing test failures.  I don't know what to do 
about this.

There are a bunch of calls, such as readdir() which are unsafe, but 
there is a safe version, specified by appending "_r" to the name, like 
readdir_r().  This is transparently done by reentr.h for systems that 
have them.  Thus, the code won't be safe when run on a platform that 
doesn't have the "_r" version, but will be safe on a platform that does. 
  This can lead to apparently unexplainable errors on the platforms that 
don't have them.  I suppose we could generate compile time messages when 
this happens.  Maybe you can think of something better.

Some of those _r functions are for things in POSIX, like ctime().  I did 
not check to see if a call to POSIX::asctime() for example, gets the 
reentrant treatment, and gets converted to asctime_r().  If it doesn't, 
it should.

getmntent() is unsafe.  It is called only on cygwin.  Linux (and hence I 
presume cygwin) has getmntent_r(), which is safe.  I suspect that the 
reason we don't probe for the _r version is because it's only on cygwin. 
  I think this should be added to reentr.h

I did not look much at the OS's that we aren't really maintaining, like 
os2.  I did see, for example, that strtok() is called in Netware, and is 
unsafe (in glibc anyway; and there is a strtok_r() in glibc that is 
safe).  I propose doing nothing for these.

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About