--- Begin Message ---
Daniel Quinlan <quinlan@transmeta.com> writes:
> http://www.debian.org/Lists-Archives/lsb-spec-9912/msg00018.html
1) It doesn't handle signals 100% correctly.
Agreed. Needs kernel help.
2) 'ps' shows every thread in a process.
User-level problem. One recent ps version (by Albert Calahan)
supports better display.
3) core dumps of multi-threaded codes don't contain all
the threads (or even the crashing one !)
Needs kernel support. One or two days ago somebody send a patch to
the kernel mailing list which takes an easy way out. He was producing
a separate core file for each thread. It would be much better to have
all of the data in one file but this requires designing a new binary
format.
4) getpid() doesn't return the same value for all threads
in a single process,
User-level problem. Will be fixed if the signal handling is
corrrected. It's simply necessary in the moment.
5) A child process fork()ed in one thread often cannot be
wait()ed for by a different thread, depending upon the
exact parent-child relationships between threads.
Ideally be handled in the kernel (adding a new flag for wait*() which
allows all threads to wait for children). Should be easy to implement
in the kernel. A user-level implementation would be very ugly and
costly since all forks and wait would have to be handled by one
thread.
6) Threads *have* parent-child relationships (when they
should properly all be peers).
There is a CLONE_* flag available to use signal sharing the parent.
This is also somewhat dependent on the signal handling and therefore
is delayed.
7) uid/gid information isn't common to all threads in a
single process, so (for example) a multithreaded
setuid/setgid process can have a *very* interesting time.
Can be (if necessary) be implemented on user-level. I'm not really
concerned about it. Will make a lot of operations (every syscall
which requires IDs) slower. A kernel-level solution would be faster.
8) rlimit information isn't common to all threads in a
single process.
Kernel limitation. This information would have to be shared as well.
9) A multithreaded session leader process cannot do
things like disconnecting from a controlling tty
in any thread other than its first.
Can possibly be handled at user-level. One of the things outstanding
(and awaiting a decision about the signal stuff) is to have the
manager thread running in the original LWP. In this case the request
can simply be forwarded to the manager.
10) "times" doesn't account for other than the thread it is
called in
Kernel limitation. I don't think it is worthwhile thinking about a
user-level implementation since the data will be almost useless.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
_______________________________________________
Lsb-confcall mailing list
Lsb-confcall@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/lsb-confcall
--- End Message ---