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
On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote:
Use _open internally within libc and libpthread. Have one "open"
entry point that is the cancellation version of open.
This is what it appears Solaris 7 does.
--
-- David([EMAIL PROTECTED])
To Unsubscribe: send mail to
On Thu, 13 Jan 2000, David O'Brien wrote:
On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote:
Use _open internally within libc and libpthread. Have one "open"
entry point that is the cancellation version of open.
This is what it appears Solaris 7 does.
Yeah, I've noticed
On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote:
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
On Thu, 13 Jan 2000, Jason Evans wrote:
On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote:
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,
[CCed to -hackers since this may be of general interest.]
On Wed, Jan 12, 2000 at 11:21:41PM -0800, David O'Brien wrote:
I'm still a little puzzled why every call to open got changed to
_libc_open rather than do the magic w/in open().
Consider as an example that open() is a thread
6 matches
Mail list logo
