This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Gsoc 2014 project proposal
- From: Andrea Francesco Iuorio <andreafrancesco dot iuorio at gmail dot com>
- To: libc-alpha at sourceware dot org
- Date: Thu, 27 Feb 2014 10:42:33 +0100
- Subject: Re: Gsoc 2014 project proposal
- Authentication-results: sourceware.org; auth=none
- References: <CAMaJsKjobBfmxjBRB2WP6MMLiAAD=QTV3bhO=hogeZHxmmotPg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402261759390 dot 11728 at digraph dot polyomino dot org dot uk> <CAMaJsKg-4WTvX+XPYXMYXHZvRvUotyYeq7O69Xye4WBE7Zw6Wg at mail dot gmail dot com> <530ED801 dot 4000205 at redhat dot com> <CAMaJsKgzSFnT20Bhyn6XyX+Dqk3D3TBqYcJDm8Ym-yDscftr1Q at mail dot gmail dot com>
2014-02-27 9:02 GMT+01:00 Rich Felker <dalias@aerifal.cx>:
> I think your use of the word "userspace" is somewhat imprecise; if
> you're using it to mean that libpthread is something outside of "the
> implementation" and in the domain of what applications can
> override/replace, you're wrong. Formally (wrt POSIX), the pthread
> functions are just as much a part of the implementation as stdio,
> locale, etc. With regards to implementation, glibc (including its
> dynamic linker) assumes properties of its own implementation of
> pthreads. Long long ago there was a time when you could treat it like
> a "third party library" and swap out one libpthread for another; the
> only reason this was possible is that none of them were removely
> correct with regard to POSIX semantics.
>
> What Joseph meant about namespaces is that pure ISO C applications
> which are not written to POSIX are not forbidden from using the
> pthread_* namespace for their own purposes, possibly defining external
> functions which would seem to conflict with pthreads. This does not
> make it valid to interpose alternate pthread implementations in a
> program using anything from POSIX that's not in ISO C; rather it just
> means these identifiers are not "special" with respect to ISO C, and
> thus an implementation where programs written to plain ISO C end up
> indirectly referencing these non-reserved identifiers as part of
> calling standard functions is non-conforming.
>
> Rich
Ok, but for ISO C POSIX threads are just a "third party library". For
"userspace" i mean that pthread is separate from the standard core
library ( and its implementaton ) since, as you notice, one can use
posix names as they want in standard C. I know this definition is
incorrect since even the glibc is "real" userspace code, but i think
it could give the idea that, for ISO C, POSIX is a simple external
library and not something reserved and i should treat it as that.
Since i' ll use pthread function for the implementation of some
standard functions, i can' t reserve posix functions/types names and,
if i get it right, this is my problem.
--
Andrea Francesco Iuorio
Student in Computer Science, Università degli Studi di Milano
andreafrancesco.iuorio@gmail.com - GPG Key