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 extens
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 potenti
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
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
> 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 po
[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 cancellati
6 matches
Mail list logo
