Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 07 Oct 2004 17:36:44 -0500
From:      Mark Gooderum <mark@verniernetworks.com>
To:        Daniel Eischen <deischen@gdeb.com>
Cc:        freebsd-threads@freebsd.org
Subject:   Re: threads/72429: threads blocked in stdio (fgets, etc) are not cancellable in 5.3 (works in 4.x)
Message-ID:  <4165C4FC.2010607@verniernetworks.com>
In-Reply-To: <Pine.GSO.4.43.0410071721330.1700-100000@sea.ntplx.net>
References:  <Pine.GSO.4.43.0410071721330.1700-100000@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Uncle.  Okay - you're right, sigh.

It's not so much that we're using fgets() as many/most C based parsing 
libraries use stdio, bleh.

As for why libc_r is cancellable...

In 4.x  _foo() sets the cancellation state and calls __foo() (for read, 
write, et.al), in 5.3 it's reversed. 
--
Mark

>On Thu, 7 Oct 2004, Mark Gooderum wrote:
>
>  
>
>>But this is a major change in behavior from FreeBSD 4 and also a
>>difference from Linux.  I'm not a Linux bigot at all but there is a
>>recurring theme that XX threaded apps works on Linux but is unstable on
>>FreeBSD and these sort of major behavior deltas contribute to the
>>perception of FreeBSD threading as unstable by some.
>>    
>>
>
>If you want to be portable, you should be using select() or
>poll().  It's not like there is no portable way of doing
>what you want, and in fact relying on fgets() to be cancellable
>is not portable.
>
>  
>
>>In fact it means that any thread doing blocking stdio is uncancellable -
>>the standard may not require it but many applications might expect it.
>>Given that the functionality was there in 4.x and lost in 5.x I'd call
>>it a regression.
>>    
>>
>
>fgets() was not supposed to be cancellable in 4.x.  If it
>is, it is not by intention.  Anything that calls _foo (single
>underscore versions of system calls) is intentionally doing
>it that way to avoid entering undesired cancellation points
>(and blocking points in the case of libc_r).  There are other
>uses of _read() within libc and those may not want to be
>cancellation points.
>
>The overall design of libc is that all internal uses of system
>calls use the single underscore versions and let the threads
>library override them if it wants.  _foo() is not supposed to
>be cancellable, and, in the case of libc_r, is also not supposed
>to allow the process to block when hit (libc_r converts _read()
>and _write() to poll(), then switches to another thread).  I
>don't know why fgets() ends up as a cancellation point in libc_r,
>but it shouldn't be by design -- it is a bug.
>
>  
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4165C4FC.2010607>