[ Attempted to clean up citations, apologies if I mis-attribute
something ]
In article <[EMAIL PROTECTED]>,
Kamal R. Prasad <[EMAIL PROTECTED]> wrote:
Kamal>--- Julian Elischer <[EMAIL PROTECTED]> wrote:
Julian> Kamal R. Prasad wrote:
Kamal>>--- Julian Elischer <[EMAIL PROTECTED]> wrote:
Julian>>Kamal R. Prasad wrote:
Kamal>>>Maybe the freebsd implementation should implement
Kamal>>>NPTL in entirety.
Julian>>NPTL?
Julian>>New Pthreads Library from Library?
No, Native POSIX Threads Library for Linux. It's a Linux
implementation of kernel-level threads that was spearheded by
Ulrich Drepper. It fixes most (all?) of the ugly signal problems
that LinuxThreads had.
Kamal>>Yes.
Julian>>isn't that GPL'd?
Yes.
Kamal>No -it is a standard. The linux implementation of nptl
Kamal>is gpl'ed.
No, POSIX 1003.1 is the standard, the thread portion was known for
some time as 1003.1c, but was combined in with the base.
NPTL is a particular (less brain damaged than LinuxThreads)
implementation of the POSIX thread standard.
Likewise, scheduler activations are a decent implementation of
threads. I'll refrain from commenting further about libc_r.
Julian> so how does that differ from what we have ... a
Julian> native pthreads library?
Kamal>I just said if it was conformant with NPTL, thread and
Kamal>process scheduling would co-exist.
Uh, as far as I understand, in NPTL, each thread gets a scheduler
slot, and it is my understanding that there is nothing to protect
against the issue that Julian is asking about (1000 threads of a
single process *do* get 1000 times the time slices).
Whether that is a bug or a feature depends very heavily on the
system load.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
