Date: Thu, 13 Jan 2000 18:00:45 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Jason Evans <jasone@canonware.com> Cc: hackers@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile Message-ID: <Pine.SUN.3.91.1000113165939.267A-100000@pcnet1.pcnet.com> In-Reply-To: <20000113135010.L302@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, 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.
>
> It isn't adequate to only have two names with a libpthread. There has to
> be:
>
> 1) _open() -- A name to access the actual system call.
>
> 2) _libc_open() -- A name that libc uses internally which by default is the
> same as _open(), but can be overridden.
I don't think we need 2)
>
> 3) open() -- The name that an application uses (and cancellation point).
>
> As mentioned in my previous email, if we were to remove _libc_open() and
> use open() instead inside of libc, we would incorrectly propagate
> cancellation points.
Right, use _open instead.
>
> If we were to remove _libc_open() and use _open() instead inside of libc,
> then we would have the problem of some libc functions using system calls
> directly, where libpthread needs to do call conversion and/or extra
> bookkeeping work. (I experienced this problem in tests first-hand while
> doing the conversion; hence the renaming of functions in libc_r.)
Forget about libc_r for the moment. It's on it's last breath. Think
about the thread system proposed in -arch. It is OK to have libc
make system calls directly, because when they block, you'll get an
upcall in another context when libpthread is linked in. If libpthread
isn't linked in, then the call just blocks.
Having _libc_open() used internally within libc doesn't allow libpthread
to override _libc_open() because the linker has already resolved
references to _libc_open() within libc to the _libc_open() that is
in libc, not the _libc_open() in libpthread. Boy, that looks and
sounds awfully strange as I re-read it ;-)
I think you'd have to modify the linker to make this work the way
you envision - jdp could tell you better.
>
> We can argue about names, but I don't see any way to get around having
> three names. That said, I get momentarily confused about this every time I
> have to think about it, so if I'm really missing something, please help me
> to figure it out. =)
I know, it confuses me a bit too ;-) I'm not 100% sure of the way the
linker works, but my [last] understanding was that references to weak symbols
within libc, would be resolved to libc, and that you couldn't override
these from another library (libpthread). I hope that I'll be corrected
if I've got this wrong.
I'm not sure that it matters much anyways, because we don't need to
override references to blocking system calls (at least with the
proposed threading architecture). Some things will need to be
overridden, though, such as locking mechanisms.
I noticed that Solaris has all the pthread mutex/condvar calls in
libc, and they're all weak symbols. They must be null bodies because
if you write a program to lock a mutex twice (without linking in
libpthread), you don't get an error and it doesn't hang on the second
lock attempt.
>
> > How are you going to handle locking inside libc, if the locking
> > functions are not inside libc?
>
> I dunno. =) Seriously, I haven't given much thought to this yet, and can't
> claim to understand all the issues involved.
I guess you'll learn :-) I can think of 2 different methods:
1. Locking routines would be fully implemented within libc.
2. Locking routines have null bodies in libc, and are implemented
in libpthread, and
a. Modify the linker to allow references to weak symbols
within libc, to be overidden from libpthread, or
b. Use function pointers to access the necessary functions
which libpthread can overwrite with the fully implemented
versions.
I kind of like 2b because it seems easier.
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?Pine.SUN.3.91.1000113165939.267A-100000>