This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Roland McGrath <roland@frob.com> writes: > Do you say this based on the presumption that one must be able to easily > tell whether a given pointer is a valid thread ID or not? This is what the specification says for some of the functions (pthread_join). We can of course choose to ignore it but it's a bit more problematic. Just assume this code: pthread_create (&t, ...); pthread_join (t, ...); There is no guarantee that the newly created thread already terminated when the join operation starts. It might even be that there is a new thread with this thread handle and so the join is for a different thread. > I believe this weaker specification allows those calls to crash when given > an invalid thread ID. At least the definition is unspecified. > That seems reasonable enough to me. The main downside to this is the need > to resize the indirection table as the number of threads grows. Well, there are techniques available to reduce the costs of this. > For the x86 segment register trick, you can do a very similar thing just > with another special declaration. Either: > > extern struct thread_internal *_self asm("%gs:0"); > inline struct thread_internal *thread_self() { return _self; } > > or: > > extern struct thread_internal _self asm("%gs:0"); > inline struct thread_internal *thread_self() { return &_self; } The second case does not work (try it, you get a wrong use of %gs) and overall this is not the same. In your case the compiler has to waste a register for the thread data pointer. If you look at the code in linuxthreads you'll see that I've written the code so that I directly access the thread data through the %gs register with an non-zero offset. This makes a big difference for this stupid architecture. If you can find a way to modify your code appropriate it's certainly better. But I haven't found a possibility. > Hmm. On the contrary, I would think that the OS-specific kernel interface > part would be mostly machine-independent (since the OS takes care of > abstracting the state it maintains). Conversely, some implementation > models do preemptive thread context switching purely in user mode (e.g. the > scheduler activations model); so the "user part" is then responsible for > the highly machine-dependent details of saving a preempted user thread's > state and restoring previously saved context. Well, yes, of course this part is also dependend. But there is already functionality to do this in the libc API (swapcontext etc). > But it can easily be a decision made at source level via sysdeps > typedefs/macros whether to include a "kernel thread" data structure > directly in the pthread data structure or to use a pointer to a > separately allocated structure. Makes sense. But we should forsee this right from the beginning. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |