PK59693: PROBLEM USING POPEN() IN A MULTI THREADED ENVIRONMENT.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Problem using popen() in a multi-threaded environment.
  
  Setup:
  A master process is protecting a resource using a mutex
  semaphore #1:
    RESOURCE #0001: NAME=Mutex Object ADDR=21F39A78
  The master process set a pthread_atfork() handler to lock
  the semaphore before the fork; after the fork, parent and
  child are unlocking() the semaphore.
  
  Scenario:
  The mutex semaphore #1 is unlocked.
  The master process is starting 10 threads in a row and waiting
  as each thread is starting a child using popen("Child
  Name","r"), and also waiting for the child exit with pclose()
  and the thread is exiting.
  
  Failure:
  Only one child was successfully started and was exiting.
  But the rest of the threads are locked.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: Multithreaded C/C++ applications that        *
  *                 register fork handlers and directly          *
  *                 or indirectly (e.g. popen()) call fork().    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Processing of the prepare fork          *
  *                      handlers in fork() uses a mutex to      *
  *                      lock the fork handler queue during      *
  *                      traversal of the queue and execution    *
  *                      of the prepare handlers.  A timing      *
  *                      window exists in a multi-threaded       *
  *                      environment in which other threads      *
  *                      may deadlock waiting for this mutex.    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  See problem description.
  

Problem conclusion

• The locking code around the processing of the prepare
  handlers is not really necessary and has been removed
  to eliminate the possibility of a deadlock.
  
  In a multi-threaded application, users must insure that all
  fork handlers required by the application are registered
  prior to calling fork() from any thread.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UK36980 UK36981

Modules/Macros

• CELHFORK CELQFORK EDC40129
  

Fix information

• Fixed component name

  LE C LIBRARY

• Fixed component ID

  568819805

Applicable component levels

• R740 PSY UK36980

     UP08/06/25 P F806

• R750 PSY UK36981

     UP08/06/25 P F806

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.