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>