Date: Thu, 13 Jan 2000 07:18:12 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: jasone@canonware.com, obrien@NUXI.com Cc: hackers@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile Message-ID: <200001131218.HAA05212@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> Consider as an example that open() is a thread cancellation point according > to POSIX. If libpthread overrides the libc open() with its own version of > open(), then by extension, every function that calls open() can potentially > cause thread cancellation. This propagation of cancellation points is > legal in a specified list of libc functions, but POSIX also says that *no* > functions not in that list may act as cancellation points. That means that > we have to be absolutely sure not to propagate cancellation points within > libc, and short of constructing and analyzing a full call graph of the libc > internals, this is the only way (that I can think of) to assure that libc > doesn't incorrectly propagate cancellation points. Use _open internally within libc and libpthread. Have one "open" entry point that is the cancellation version of open. > So, once we switch from libc_r to libpthread, we will have to implement, > for example open() and _libc_open() in libpthread, where open() tests for > cancellation, then calls into _libc_open(), which does the real work and > presumably culminates in a call to _open(). In fact, we can probably make > cancellation work correctly even in libc_r now, but I'll convert to > libpthread first (the order these things are done in doesn't matter much). How are you going to handle locking inside libc, if the locking functions are not inside libc? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001131218.HAA05212>