Re: newlib stdio and thread cancellation

[Corinna Vinschen <vinschen at redhat dot com>]

On May 25 19:31, Steven Abner wrote:
> 
> On May 23, 2012, at 9:08 AM, Corinna Vinschen wrote:
> 
> > Consider a scenario where multiple threads call printf.  The vfprintf
> > function is secured against concurrent usage of the same descriptor
> > by calling _flockfile/_funlockfile.
> 
> Corinna, I have a question. I am not sure why concurrent or serialization
> of parsing is needed. Wouldn't that defeat the purpose of threading? I can
> see actual syscall write locking a descriptor, but what if 3 threads use
> vfprintf on one descriptor, does it matter which thread writes first, or in the
> case of one being canceled, that only 2 write in a certain sequence?
> I ask in earnest, because I viewed from a different position.
> I saw vfprintf as a userland function which should perform its
> operation of parsing and once done, to send off for writing.

vfprintf is just one example of a whole bunch of stdio functions calling
_flockfile/_funlockfile.  The idea of this lock is not to avoid multiple
threads writing concurrently on a stream in the first place, but to
secure the FILE structure of a stream against concurrent, conflicting
manipulation.  Without this, the stdio functions are not thread-safe,
and per POSIX they are supposed to be.

The problem we still have to fix is that these functions, while being
generally thread-safe, are not safe against thread cancellation.  If a
thread holding a FILE lock is cancelled, the lock is not unlocked and
all subsequent I/O on this stream will hang trying to lock the stream.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat