Messages in this thread | | | Date | Mon, 31 Jan 2000 23:15:47 +0300 (MSK) | From | Khimenko Victor <> | Subject | Re: POSIX threads library for Linux |
| |
On Mon, 31 Jan 2000, Jun Sun wrote:
> Khimenko Victor wrote: > > > > In <Pine.SOL.3.96.1000131184942.27017A-100000@cdacb> David SelvaKumar (david@cdacb.ernet.in) wrote: > > > > > hello all, > > > could anybody suggest about Threads implementation which > > > implements the entire POSIX threads std. 1003.1c.i for linux. > > > > AFAIK there are no such implementation. All REQUIRED things are implemented > > in LinuxThreads from glibc ... > > Where can I get more information about the LinuxThread?
Hmm. It's part of glibc 2.x so it should be discussed on glibc's mailing lists (see http://sourceware.cygnus.com/glibc/ for more info)... Kernel changes (if they are really needed) should be discussed also @ l-k, of course...
> Specifically is it implemented by processes sharing the same address > space or by user-level threads? > It's kernel-thread library (based on clone).
> Also, do you mean there is NO POSIX threads implementation in Linux at > all?
There are few. Both kernel-threads based and userspace versions exists. LinuxThreads is most common though. But if by "POSIX threads" you mean "POSIX threads with all OPTIONAL bells and whistles" then answer is "NO". There are NO threads library with all OPTIONAL features implemented. LinuxThreads (and others) implement all REQUIRED features but not OPTIONAL ones.
> That does not sound right to me, although I have not checked it out > myself. > Reason is simple in fact: Linux do not need any certificates :-) So only usefull things from different specifications are implemented. When something is REALLY usefull or easy to implement it's implemented. If not - then not.
> > > > P.S. This thread does not belond to linux-kernel till there are no working > > implementation with complimentary kernel changes: when such implementation > > will be created talks about adding of kernel changes to mainstream kernel > > can be started... inheritance/ceiling properties should not require kernel > > modifications though... > > > > If threads are implemented as processes sharing the same address space, > we do need to modify kernel to implement priority inheritance. > They are implemented this way but if you are thinking about such changes then you must have VERY VERY strong arguments for ANY changes in sheduler. And no "it's defined by POSIX so it should be implemented" is not strong argument. It's not even weak argument :-) It's not argument at all. The ONLY arguments here are NUMBERS. You should be ready to show REAL-WORLD example where such changes are needed to improve something (speed, responsibility, etc) and last but not least where there are NO NATURAL WAY TO SOLVE PROBLEM WITHOUT INTRODUCING such new concept. Linux developers are VERY fast in adding features as far as said features do not affect innocent code :-) But when feature affects "common path" task immediately become MUCH harder: for example STREAMS support was rejected by that reason (even if there are exist implementation and some important programs where STREAMS are used :-)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |