This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

newlib stdio and thread cancellation


I'm just debugging a problem in Cygwin in terms of pthread cancellation.

Consider a scenario where multiple threads call printf.  The vfprintf
function is secured against concurrent usage of the same descriptor
by calling _flockfile/_funlockfile.

If pthread_cancel is called on a thread while it's executing printf,
_funlockfile is never called, because newlib's stdio functions neglect
to push/pop pthread cleanup handlers.

The result are spurious hangs, because the next stdio function on the
affected descriptor will hang in _flockfile.

While this might be of no interest for embedded targets, it's a really
serious problem for Cygwin or any other system implementing thread

There are two possible solutions:

- The target specific lock/unlock functions push and pop the cleanup
  handlers on their own.  I just implemented this for Cygwin but didn't
  check in yet.  This can become really awkward, depending on the
  underlying pthread implementation.

- The IMHO right thing to do would be to change newlib's stdio functions
  to call pthread_cleanup_push/pthread_cleanup_pop as necessary.  This
  could be combined with a matching ifdef, for instance:

    _flockfile (fp);
    pthread_cleanup_push (flockfile_cleanup, (void *) fp);


    pthread_cleanup_pop (1);
    _funlockfile (fp);

Does anybody know another solution or would it be ok to add the
aforementioned functionality to newlib?


Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]