threads/72429: threads blocked in stdio (fgets, etc) are not cancellable in 5.3 (works in 4.x)

[Daniel Eischen]

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.

-- 
Dan Eischen