clone vs pthread_create
PX
For multithreaded programming on Linux, what's the big difference between
clone() and pthread_create()? All I know is clone() is claimed to
implement pthread. Is there any difference regarding performance and
stability issues?
Any comments about which one to choose under what circumstances?
Thanks a lot.
PX
Marc Rochkind
"PX" <rya...@yahoo.com> wrote in message
news:b5q0j3$lf6$1...@license1.unx.sas.com...
Don't use clone. It's nonstandard, and full of all sorts of restrictions
that make it very hard to use. It's there only to implement pthread_create.
However, the pthread_create it helps implement doesn't conform to the
standard, because each thread is a process with memory and other resources
shared. The documentation for Linux threads lists a bunch of
restrictions--ways in which they are not POSIX Threads.
However, until some revisions are made to Linux, that's all you've got.
--Marc
David Schwartz
> However, the pthread_create it helps implement doesn't conform to the
> standard, because each thread is a process with memory and other resources
> shared.
Actually, each thread is not a process. By definition, all the threads
created with 'pthread_create' belong to the same process. Or, to put it
another way, by definition, the word "process" refers to all the threads
that share their memory and file descriptors.
The problem is that Linux only has one type of kernel scheduling entity
and the kernel doesn't know the difference between a process and a
thread. So functions like 'getpid' actually return a kernel scheduling
entity identifier which shares namespace with true process identifiers.
DS
Marc Rochkind
I was going by the first sentence of the clone man page: "clone creates a
new process". The whole page talks about "processes." They need another
term, I guess.
--Marc
David Schwartz
They're using the term "process" to mean, roughly, "anything scheduled
by the kernel". I'm betting that this is a result of a copy/paste from
the fork man page. Using the term 'KSE' (Kernel Scheduling Entity) is
ugly.
DS
Marc Rochkind
"David Schwartz" <dav...@webmaster.com> wrote in message
news:3E80CEC3...@webmaster.com...
[snip]
> ugly.
Who cares? If we wanted pretty documentation, we could read about Windows!
;-)
Anyhow, I think I'll stick a footnote to this effect in my forthcoming book.
--Marc
Casper H.S. Dik
> The problem is that Linux only has one type of kernel scheduling entity
>and the kernel doesn't know the difference between a process and a
>thread. So functions like 'getpid' actually return a kernel scheduling
>entity identifier which shares namespace with true process identifiers.
That is stretching my definition (and the standard's) of process by
quite a bit; the definition of process surely is an entity in which
getpid() returns the same value.
The first part of your first sentence has no bearing on the problem;
the Solaris kernel also only has one scheduling entity yet it has
both processes and threads.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Patrick TJ McPhee
David Schwartz <dav...@webmaster.com> wrote:
% Marc Rochkind wrote:
%
% > However, the pthread_create it helps implement doesn't conform to the
% > standard, because each thread is a process with memory and other resources
% > shared.
%
% Actually, each thread is not a process.
You can say this as much as you like and stamp your feet if it makes
you feel better, but the fact is that threads on Linux are processes.
They may have some of the attributes of a thread, but they have separate
process IDs, and this leads to non-conformance in sometimes important ways.
It's not simply a matter of scheduling, and it can't be fixed by simply
changing the code to PS, getpid(), getppid() and a myriad other functions
and programs which depend on all the threads of a process sharing a process
ID. If it were a simple problem, it would be fixed already.
Effectively what you are saying when you spout this nonesense is that the
Linux threads developers are incompetent, or that there isn't a problem
related to the lack of a process/thread distinction. This is insulting,
incorrect, and not especially helpful to people who are having problems.
Duke Robillard
> In article <3E80C1EF...@webmaster.com>,
> David Schwartz <dav...@webmaster.com> wrote:
> % Marc Rochkind wrote:
> %
> % > However, the pthread_create it helps implement doesn't conform to the
> % > standard, because each thread is a process with memory and other resources
> % > shared.
> %
> % Actually, each thread is not a process.
>
> You can say this as much as you like and stamp your feet if it makes
> you feel better, but the fact is that threads on Linux are processes.
I think it's a matter of definitions here. The Linux guys
use the word "process" to define the entity you get by
calling "clone()." The Linux model isn't 100% compatible
with the POSX model, so this entity might not be what POSIX
means by the word "process." But "process" is the word Linux
uses for it. When in Rome, you do as the Romans do, so I
call it a "process."
It's also not what POSIX means by the word "thread" (it has
a parent-child relationship with the creator, has a separate
PID, etc, etc).
It's as if you were on VMS. You might use the word "process"
to describe things, but they probably won't fit the POSIX
definition.
Duke
Tony Gale
pt...@interlog.com (Patrick TJ McPhee) writes:
> In article <3E80C1EF...@webmaster.com>,
> David Schwartz <dav...@webmaster.com> wrote:
> % Marc Rochkind wrote:
> %
> % > However, the pthread_create it helps implement doesn't conform to the
> % > standard, because each thread is a process with memory and other resources
> % > shared.
> %
> % Actually, each thread is not a process.
>
> You can say this as much as you like and stamp your feet if it makes
> you feel better, but the fact is that threads on Linux are processes.
> They may have some of the attributes of a thread, but they have separate
> process IDs, and this leads to non-conformance in sometimes important ways.
>
> It's not simply a matter of scheduling, and it can't be fixed by simply
> changing the code to PS, getpid(), getppid() and a myriad other functions
> and programs which depend on all the threads of a process sharing a process
> ID. If it were a simple problem, it would be fixed already.
Like what has already been done on Linux in both NGPT and NPTL you mean?
>
> Effectively what you are saying when you spout this nonesense is that the
> Linux threads developers are incompetent, or that there isn't a problem
> related to the lack of a process/thread distinction. This is insulting,
> incorrect, and not especially helpful to people who are having problems.
>
Thats not at all what David "effectively" said.
-tony
Alexander Terekhov
Patrick TJ McPhee wrote:
[ ... Actually, each thread is not a process. ... ]
> Effectively what you are saying when you spout this nonesense is that the
> Linux threads developers are incompetent, ...
Nah, that means that in the past, a whole bunch of influential Linux
KERNEL developers were not-really-competent with respect to threads
and POSIX in general. (now, primarily [AFAIK] due to NGPT's [RIP] and
NPTL's teams efforts, there is a chance that things might get better
in the not-so-distant future)
http://old.lwn.net/2000/0330/kernel.php3
<quote>
POSIX threads. The issue of support in the Linux kernel for POSIX
threads came up again this week. Many people who are looking for a
clean, cross-platform implementation of threads get frustrated that
they are not fully supported by the Linux kernel. The final answer
is that they won't be implemented. The concensus among the primary
kernel developers appears to be that doing a POSIX threads
implementation is impossible to do both correctly and efficiently.
Here's a sample of some of the opinions:
Alan Cox:
"posix threads is a braindamaged pile of crap".
Stephen Tweedie:
"although a lot of the POSIX threads are reasonable, things
like requiring uid/gid updates to be instantly effective
across all threads in the process are just insane".
Linus Torvalds:
"Note that the reason the kernel is not POSIX-compliant is:
- the POSIX standard is technically stupid. It's much better
to use a cleaner fundamental threading model and build on
top of that.
- things like the above are just so much better and more
easily done in user space anyway."
For those people in a pickle as to what to do as a result, Linus
suggested they take a look at the netscape/mozilla threading
library.
</quote>
regards,
alexander.
David Schwartz
> In article <3E80C1EF...@webmaster.com>,
> David Schwartz <dav...@webmaster.com> wrote:
> % Marc Rochkind wrote:
> % > However, the pthread_create it helps implement doesn't conform to the
> % > standard, because each thread is a process with memory and other resources
> % > shared.
> % Actually, each thread is not a process.
> You can say this as much as you like and stamp your feet if it makes
> you feel better, but the fact is that threads on Linux are processes.
This is a just an outright contradiction. A process has its own address
space by definition.
> They may have some of the attributes of a thread, but they have separate
> process IDs, and this leads to non-conformance in sometimes important ways.
Certainly.
> It's not simply a matter of scheduling, and it can't be fixed by simply
> changing the code to PS, getpid(), getppid() and a myriad other functions
> and programs which depend on all the threads of a process sharing a process
> ID. If it were a simple problem, it would be fixed already.
Agreed.
> Effectively what you are saying when you spout this nonesense is that the
> Linux threads developers are incompetent, or that there isn't a problem
> related to the lack of a process/thread distinction. This is insulting,
> incorrect, and not especially helpful to people who are having problems.
Huh? How do you figure? The problem is primarily that the kernel
doesn't care about processes or threads, supporting only a single type
of KSE.
DS
David Schwartz
> >The problem is that Linux only has one type of kernel scheduling entity
> >and the kernel doesn't know the difference between a process and a
> >thread. So functions like 'getpid' actually return a kernel scheduling
> >entity identifier which shares namespace with true process identifiers.
> That is stretching my definition (and the standard's) of process by
> quite a bit; the definition of process surely is an entity in which
> getpid() returns the same value.
Except Linux has no 'getpid' function. It has a function that is called
'getpid' but it actually does not return a process ID, it returns a KSE
ID.
> The first part of your first sentence has no bearing on the problem;
> the Solaris kernel also only has one scheduling entity yet it has
> both processes and threads.
That's why the word "and" is in that sentence.
DS
David Schwartz
> You can say this as much as you like and stamp your feet if it makes
> you feel better, but the fact is that threads on Linux are processes.
> They may have some of the attributes of a thread, but they have separate
> process IDs, and this leads to non-conformance in sometimes important ways.
I will just state the SuSv3 definition of a "process":
An address space with one or more threads executing within that address
space, and the required system resources for those threads.
Note that a process, by definition, means all the execution vehicles
that share a particular address space.
DS
Marc Rochkind
"Alexander Terekhov" <tere...@web.de> wrote in message
news:3E81F4B9...@web.de...
[snip]
> The final answer
> is that they won't be implemented. The concensus among the primary
> kernel developers appears to be that doing a POSIX threads
> implementation is impossible to do both correctly and efficiently.
[snip]
Yikes! I thought that Linux was moving towards POSIX, and was in addition
asking the UNIX community to forgive the motion (that they were not there
yet) because of the nature of open-source development vs. top-down,
hiearchical, corporate development.
But now, if the above is correct, they are saying that they won't conform
because the POSIX interface is wrong/inefficient/inadequate/whatever?
So, what, we should dump POSIX and dump the quest for portability?
Ouch!
I should note that it is perfectly OK if an OS has two interfaces for
something, one standardized and one optimized and superior. This is often
true, and not only of OS APIs. (For example, one well-known imaging library
supports JPEG and also a proprietary compression scheme that's much better.)
Solaris has two thread APIs. BSD systems have two APIs for locking files.
And so on... I would think that anyone writing a portable program would know
that it won't be locally optimal on every system it runs on. But, still,
having it RUNNING is a huge help when it comes time to replace the generic
calls with system-specific ones.
Also, for educational purposes, it is very helpful if the students can do
the exercises regardless of the system they're on. And, of course, many
students who want to learn the standard interfaces will be running Linux in
their dorm rooms.
One more thing: If you're implementing a library with functionality X, don't
use the interface for Y. It confuses everyone. If pthread_create isn't going
to do pthread_create, name it lthread_create.
I think I'll stop here. ;-)
--Marc
Patrick TJ McPhee
Tony Gale <ga...@dstl.gov.uk> wrote:
% In article <b5sj1k$ool$1...@news.eusc.inter.net>,
% pt...@interlog.com (Patrick TJ McPhee) writes:
% > ID. If it were a simple problem, it would be fixed already.
% Like what has already been done on Linux in both NGPT and NPTL you mean?
Which Linux distributions use these and not LinuxThreads? All of them?
Most of them? Any of them? Do these resolve all or most of the problems?
I have no trouble with someone saying `this is resolved in NPTL, so
change to a distribution which uses NPTL', but this is not what has been
said so far.
% > Effectively what you are saying when you spout this nonesense is that the
% > Linux threads developers are incompetent, or that there isn't a problem
% > related to the lack of a process/thread distinction. This is insulting,
% > incorrect, and not especially helpful to people who are having problems.
% Thats not at all what David "effectively" said.
Then what is he saying?
David has said that there is a bug in ps -- it returns an entry for
every thread, not one for every process. Is this not due to incompetence
on the part of the thread developers? What other explanation can there
be, since the problem is simple to fix? He says that Linux does not have
a getpid function, merely a function called getpid(), which happens to
do what you might expect if you have a single-threaded program, but
doesn't do what you might expect if you have a multi-threaded program.
Is this not due to incompetence? What other explanation can there be?
The problem, after all, is quite simple to fix. And yet, it's been going
on for years, and people continue to have it every day.
Or perhaps there isn't really a problem. It seems like lately, whenever
anyone says that `threads are processes' in Linux to explain anomalous
behaviour on that platform, David pops up to say that they aren't. Since
they obviously are -- to me the most basic definition of a process is
something to which the system assigns a process ID, and to me the
process ID is the number returned by getpid() -- I have to wonder what
his motives are. If it's not to point out someone's incompetence, then
perhaps it's to say that there is no problem and no effort should be
wasted trying to fix it, or inform people about it.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Alexander Terekhov
Marc Rochkind wrote:
[...]
> Yikes! I thought that Linux was moving towards POSIX,
*NOW* Linux IS moving towards POSIX {threads, etc.}. I wrote: IN THE PAST.
> and was in addition
> asking the UNIX community to forgive the motion (that they were not there
> yet) because of the nature of open-source development vs. top-down,
> hiearchical, corporate development.
>
> But now, if the above is correct, they are saying that they won't conform
> because the POSIX interface is wrong/inefficient/inadequate/whatever?
http://www.onlamp.com/pub/a/onlamp/2002/11/07/linux_threads.html?page=2
(Note that NGPT was recently "declared to be dead"; just like LinuxThreads)
>
> So, what, we should dump POSIX and dump the quest for portability?
You should subscribe to the NPTL's mailing list and provide your feedback
{and contributions} to Drepper&Co with respect to ongoing NPTL developments.
regards,
alexander.
David Schwartz
> % > Effectively what you are saying when you spout this nonesense is that the
> % > Linux threads developers are incompetent, or that there isn't a problem
> % > related to the lack of a process/thread distinction. This is insulting,
> % > incorrect, and not especially helpful to people who are having problems.
> % Thats not at all what David "effectively" said.
> Then what is he saying?
I think the words I've actually said make it pretty clear what I'm
saying. There's a logjam between the pthreads folks and the kernel folks
and as a result, Linux doesn't follow the POSIX standard. I'm not
blaming either side, as both sides views make sense independent of the
other side.
> David has said that there is a bug in ps -- it returns an entry for
> every thread, not one for every process.
Yes, I stand by this claim.
> Is this not due to incompetence
> on the part of the thread developers? What other explanation can there
> be, since the problem is simple to fix?
It's not simple to fix, since it's not clear what's a thread and what's
a process in the kernel and having 'ps' understand internals of the
threads implementation is ugly. My understanding is that it's not even
easy for 'ps' to determine whether two KSEs share a vm.
Yes, the problem is simple to fix if the kernel, proc interface, ps,
and the threads library could all be adjusted to fix that problem. But I
respect the reasons why some of the people involved won't make the
changes.
> He says that Linux does not have
> a getpid function, merely a function called getpid(), which happens to
> do what you might expect if you have a single-threaded program, but
> doesn't do what you might expect if you have a multi-threaded program.
I stand by this claim.
> Is this not due to incompetence? What other explanation can there be?
> The problem, after all, is quite simple to fix. And yet, it's been going
> on for years, and people continue to have it every day.
The explanation is that the changes don't make sense to the kernel
developers.
> Or perhaps there isn't really a problem. It seems like lately, whenever
> anyone says that `threads are processes' in Linux to explain anomalous
> behaviour on that platform, David pops up to say that they aren't. Since
> they obviously are -- to me the most basic definition of a process is
> something to which the system assigns a process ID, and to me the
> process ID is the number returned by getpid()
I stand by the SuSv3 definition of 'process' and common sense. A
process is all the execution vehicles that share an address space.
> -- I have to wonder what
> his motives are. If it's not to point out someone's incompetence, then
> perhaps it's to say that there is no problem and no effort should be
> wasted trying to fix it, or inform people about it.
Do you really think that if I felt that way, I wouldn't just come right
out and say "X is incompetent" or "there is no problem, Linux is
perfect". There is a problem. The 'getpid' function doesn't return a
process ID on Linux. Linux is not SuSv3 compliant.
If you can find something I've said that's factually inaccurate, point
it out. I stand by my use of 'process' in accord with SuSv3 and common
sense. If you think blame follows naturally from the facts I've pointed
out, then that's your conclusion about who is at fault.
DS
Marc Rochkind
>
[snip]
>
> *NOW* Linux IS moving towards POSIX {threads, etc.}. I wrote: IN THE PAST.
>
[snip]
I am confused. I thought you said that a POSIX thread implementation was
dead? That, anyway, is what I was responding to.
--Marc
Tony Gale
pt...@interlog.com (Patrick TJ McPhee) writes:
> In article <3e81e19e$0$739$69cb...@trog.dstl.gov.uk>,
> Tony Gale <ga...@dstl.gov.uk> wrote:
>
> % Like what has already been done on Linux in both NGPT and NPTL you mean?
>
> Which Linux distributions use these and not LinuxThreads? All of them?
> Most of them? Any of them? Do these resolve all or most of the problems?
> I have no trouble with someone saying `this is resolved in NPTL, so
> change to a distribution which uses NPTL', but this is not what has been
> said so far.
RedHat 9 (and the 8.1betas) use NPTL.
>
> % Thats not at all what David "effectively" said.
>
> Then what is he saying?
>
> David has said that there is a bug in ps -- it returns an entry for
> every thread, not one for every process. Is this not due to incompetence
> on the part of the thread developers? What other explanation can there
> be, since the problem is simple to fix?
Where did David say it was easy to fix? He's stated the opposite. And you
are the only person using the word 'incompetent'.
> He says that Linux does not have
> a getpid function, merely a function called getpid(), which happens to
> do what you might expect if you have a single-threaded program, but
> doesn't do what you might expect if you have a multi-threaded program.
> Is this not due to incompetence? What other explanation can there be?
> The problem, after all, is quite simple to fix. And yet, it's been going
> on for years, and people continue to have it every day.
Simple explanation: the Linux kernel didn't (note past tense) provide a
framework for implementing a POSIX style getpid, so it simply wasn't
done in LinuxThreads. It's not a huge issue. It's realatively simple to
code around in the rare instances it is needed.
>
> Or perhaps there isn't really a problem. It seems like lately, whenever
> anyone says that `threads are processes' in Linux to explain anomalous
> behaviour on that platform, David pops up to say that they aren't. Since
> they obviously are -- to me the most basic definition of a process is
> something to which the system assigns a process ID, and to me the
> process ID is the number returned by getpid() -- I have to wonder what
> his motives are. If it's not to point out someone's incompetence, then
> perhaps it's to say that there is no problem and no effort should be
> wasted trying to fix it, or inform people about it.
You're bitching about things that are already resolved. The current
Linux pthreads libraries do it right with regard to the standard.
LinuxThreads is the past, get over it.
-tony
Tony Gale
A specific implementation may be dead, but that doesn't necessarily
reflect on the standard as a whole.
LinuxThreads is dead. NGPT may be going the same way on Linux. NPTL is
taking over. Ref: http://people.redhat.com/drepper/nptl-design.pdf
The only major non-POSIX compliance listed is with setuid/setguid, and I don't
know if that has been resolved yet.
-tony
Tony Gale
Alexander Terekhov <tere...@web.de> writes:
> Linus Torvalds:
>
> "Note that the reason the kernel is not POSIX-compliant is:
> - the POSIX standard is technically stupid. It's much better
> to use a cleaner fundamental threading model and build on
> top of that.
> - things like the above are just so much better and more
> easily done in user space anyway."
>
> For those people in a pickle as to what to do as a result, Linus
> suggested they take a look at the netscape/mozilla threading
> library.
>
Keep in mind that the Linux kernel doesn't provide compliance to a particular
standard just to get a tick-in-the-box if doing so would result in a bad
design/implementation (unlike some people). Thats not what it's about.
So, now Ingo and Ulrich have done the work to get the model right, it
has been implemented and accepted into the standard Linux kernel, and is
fundamentally POSIX threads compliant.
-tony
Alexander Terekhov
Marc Rochkind wrote:
[...]
> I am confused. I thought you said that a POSIX thread implementation was
> dead? That, anyway, is what I was responding to.
Ok, I'll try again. History of the revolt against POSIX in the Linux
kernel camp aside for a moment, both LinuxThreads and NGPT are *NOW*
"functionally stabilized" (with respect to NGPT we can probably say
that it received IBM's kiss of death). NPTL is the way to go (unless,
of course, you just want to wait for "something else" to emerge and
you know something that I don't know).
The NPTL white paper can be found here:
http://people.redhat.com/drepper/nptl-design.pdf
Just to put things in perspective, you might also want to read this:
http://people.redhat.com/drepper/glibcthreads.html
regards,
alexander.
Casper H.S. Dik
> This is a just an outright contradiction. A process has its own address
>space by definition.
Not by definition or things like vfork() could not exist.
(It does work the other way around; two things cannot be the same
process if they do not share the address space)
If you look at the fork() manual page you get a pretty good idea
what needs to be shared for somethign to be a single process; it's
more than just the address space.
> Huh? How do you figure? The problem is primarily that the kernel
>doesn't care about processes or threads, supporting only a single type
>of KSE.
I don't think we care how the Linux kernel implements this;
it's just that we feel that getpid() should not return the KSEid but
rather the process id.
Arnold Hendriks
>> perhaps it's to say that there is no problem and no effort should be
>> wasted trying to fix it, or inform people about it.
> You're bitching about things that are already resolved. The current
> Linux pthreads libraries do it right with regard to the standard.
> LinuxThreads is the past, get over it.
No, you can only get over it until all your clients upgraded to a conforming
distribution :)
Any idea if, and when, other distributions will be following?
--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/
Casper H.S. Dik
> I will just state the SuSv3 definition of a "process":
>An address space with one or more threads executing within that address
>space, and the required system resources for those threads.
> Note that a process, by definition, means all the execution vehicles
>that share a particular address space.
Your rephrasing contains a logic error. The fact that a process is defined
as an address space with execution threads does not imply that any single
address space with a number of execution threads is a single
process.
Casper H.S. Dik
>One more thing: If you're implementing a library with functionality X, don't
>use the interface for Y. It confuses everyone. If pthread_create isn't going
>to do pthread_create, name it lthread_create.
Or DCEthread_create() to shame another offender.
(Object lesson: even when implementing a draft standard, make sure you
use different symbols)
Alexander Terekhov
Tony Gale wrote:
[...]
> So, now Ingo and Ulrich have done the work to get the model right,
http://www.businessweek.com/technology/cnet/stories/994074.htm
<quote>
For threading, stars have aligned for NPTL. One key endorsement came
from Linux leader Linus Torvalds, who has accepted NPTL into the 2.5
version of the Linux kernel, the test version that will be numbered
2.6 when ready for real-world use.
Another endorsement came on March 14, when IBM programmers working
on their own threading improvements--a project called Next Generation
Posix Threading--announced they were focusing their attention instead
on NTPL. "We don't want to split the community to choose one over the
other," the developers said in a statement, and NPTL has successfully
dealt with the problems the IBM team had set out to solve.
While Red Hat programmers Ulrich Drepper and Ingo Molnar were
instrumental in making NPTL a reality, IBM programmers such as Rusty
Russell also have helped, Wilson said.
</quote>
Please note that Intel programmers were also involved in the NGPT
project; including the kernel patches that are now also used by the
NPTL (AFAIK). The credit should go to ALL contributors (not only to
Drepper-and-Molnar of RedHat) who were involved in making threading
on Linux better and standard compliant.
Finally, please also note that the current NPTL-stuff is MILES away
from the "production quality", AFAICS.
regards,
alexander.
--
https://listman.redhat.com/pipermail/phil-list/2003-March/000777.html
(Subject: Re: nptl 0.30)
Christian Parpart
[........]
> Finally, please also note that the current NPTL-stuff is MILES away
> from the "production quality", AFAICS.
Nearly. I already tested a very recent NPTL using a CVS snapshot of glibc
2.3 and it was really great. My whole desktop run unter this environment.
The only reason for switching back to crappy LinuxThreads has been that all
OpenGL applications where like to be crashed somehow. And I need this
stuff.
Cheers,
Christian Parpart.
Alexander Terekhov
Christian Parpart wrote:
>
> Alexander Terekhov inspired the electrons to say:
>
> [........]
> > Finally, please also note that the current NPTL-stuff is MILES away
> > from the "production quality", AFAICS.
>
"Program testing can be used to show the presence of bugs, but never
to show their absence."
regards,
alexander.
Tony Gale
Alexander Terekhov
< attributions inserted >
-- Edsger W. Dijkstra
> >
>
> "Only fools are quoted."
-- Anonymous Fool
regards,
alexander.
Marc Rochkind
[snip]
>
> Another endorsement came on March 14, when IBM programmers working
> on their own threading improvements--a project called Next Generation
> Posix Threading--announced they were focusing their attention instead
> on NTPL. "We don't want to split the community to choose one over the
> other," the developers said in a statement, and NPTL has successfully
> dealt with the problems the IBM team had set out to solve.
>
[snip]
OK... NOW I get it! I had been using NPTL, but just yesterday switched to
NTPL, which works much better. Next week I expect to try out the new NLPT
implementation... should be very exciting! Soon, this will be moot, because
I expect that the much improved NPLT to be available next year. Silly me...
I was so confused... if I had given it a moment's thought, it all would have
been clear!
[Trying to lighten up this "thread" a bit.]
--Marc
Dragan Cvetkovic
>
> OK... NOW I get it! I had been using NPTL, but just yesterday switched to
> NTPL, which works much better. Next week I expect to try out the new NLPT
> implementation... should be very exciting! Soon, this will be moot, because
> I expect that the much improved NPLT to be available next year. Silly me...
> I was so confused... if I had given it a moment's thought, it all would have
> been clear!
Since there are 4! =24 implementations, you still have a long way to go :-)
OK, 6 if New must be the first word...
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
Patrick TJ McPhee
Casper H.S. Dik <Caspe...@Sun.COM> wrote:
% I don't think we care how the Linux kernel implements this;
% it's just that we feel that getpid() should not return the KSEid but
% rather the process id.
But also that there should be an identifier which can be used to
identify a process which, for instance, has a lock on a file, is waiting
for a semaphore, should receive a signal, has a file open, and so forth.
These are things that are handled either in the kernel or in system
services which are used by the kernel, and they can affect the way that
applications are implemented.
I just read a posting in which LinuxThreads were described as `crappy'.
I don't agree with this, but there are specific problems of which
everyone developing software for use with LinuxThreads ought to be
aware. My reading of this thread is that the problems have been
addressed with some kernel redesign and and a new thread implementation,
and that this is rolling towards release. It will be good to see
this happen, and we'll be able to put this discussion behind us.
Patrick TJ McPhee
Tony Gale <ga...@dstl.gov.uk> wrote:
% You're bitching about things that are already resolved. The current
% Linux pthreads libraries do it right with regard to the standard.
% LinuxThreads is the past, get over it.
I'm not really bitching about anything at all. I don't agree with
Schwartz's point of view on this issue, and I have explained why.
I frankly find his comments bizarre.
I am pleased to hear that the problem will be resolved once the
new kernel is released, but my understanding is that this has
not happened yet, and from the practical perspective of people trying
to implement portable software, the problem will continue to exist,
and so will need to be discussed here, until installations with the
current release kernels no longer exist.
I expect that issues with LinuxThreads will continue to pop up for the
next few years, that people will explain why, that Schwartz will deny
the explanations, and that I will find it irritating.
Duke Robillard
> Another endorsement came on March 14, when IBM programmers working
> on their own threading improvements--a project called Next Generation
> Posix Threading--announced they were focusing their attention instead
> on NTPL. "We don't want to split the community to choose one over the
> other," the developers said in a statement, and NPTL has successfully
> dealt with the problems the IBM team had set out to solve.
This is the best news I've had all week. In gratitude, I'm gonna
run out and buy a big ole IBM Blade server. :-)
BTW, alexander, your new technique of putting in an excerpt from
the link you quote is immeasurable superior to your old posting
style! Thanks for the change.
Duke
David Schwartz
> In article <3e82ba2a$0$748$69cb...@trog.dstl.gov.uk>,
> Tony Gale <ga...@dstl.gov.uk> wrote:
> I'm not really bitching about anything at all. I don't agree with
> Schwartz's point of view on this issue, and I have explained why.
> I frankly find his comments bizarre.
I just refuse to confuse a KSE with a process.
> I expect that issues with LinuxThreads will continue to pop up for the
> next few years, that people will explain why, that Schwartz will deny
> the explanations, and that I will find it irritating.
I stand by the SuSv3 definition of a "process".
DS
David Butenhof
Absolutely -- and the whole point is that Linux does not, currently, support
that definition. NPTL will, eventually, resolve that bug, but playing word
games doesn't change the fact that Linux does not currently conform to
SUSv3. You can pretend that a clone()d "thing"/KSE/LWP/whatever isn't
supposed to be a process -- but the whole point of clone() is that it IS a
process: what's usually been referred to (since long before Linux) as a
"variable weight process", meaning that you can specify how much unique vs
shared context it has.
Linux developers arrogantly (Microsoftianly?) intended that all users of
their software should be forced to do things in THEIR preferred proprietary
style rather than using portable standards. Whether out of religious
conviction that they're right and the world is wrong or out of inherently
selfish desire to limit programmer and user freedom is somewhat irrelevant.
And, apparently, they have finally been convinced to make concessions for
those who DON'T wish to be locked into proprietary solutions; by allowing
Ulrich (and many others) to provide an implementation of the portable
standard. That's good news for everyone, regardless of what you call it.
One can apply arbitrary wordsmithing to label the various points on the
access of "variable weight" in a clone()d process, and call one end
(completely unique) "process" and the other end -- well, "something"
(probably useless), because what we really need is something a bit short of
that end, with, for example, unique signal and pending masks, which we can
label "LWP" or "kernel thread".
But this is all silly and pointless semantics. What's important is that the
Linux that is currently in common use doesn't support POSIX/SUS thread and
process semantics, while the forthcoming/new NPTL version will. If you want
to play Humpty Dumpty, I can't really complain because I've been known to
indulge in that game myself: but I do have to agree with Patrick in that I
am irritated by your refusal to at least admit that you're playing a game.
This suggests you may not KNOW it's a game, and I don't like to play games
with people who think it's real...
--
/--------------------[ David.B...@hp.com ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/
Wolfram Gloger
> NPTL will, eventually, resolve that bug,
nptl is freely available _today_, so if you care enough you can easily
resolve that bug _now_.
> but playing word
> games doesn't change the fact that Linux does not currently conform to
> SUSv3.
There is no single Linux. The Linux-based system on your box may have
this particular non-conformity but others do not.
> Linux developers arrogantly (Microsoftianly?) intended that all users of
> their software should be forced to do things in THEIR preferred proprietary
> style rather than using portable standards.
Surely you're joking.. This would be a gross misrepresentation of
affairs. Nobody was forced, and "proprietary" is just ridiculous:
_Everyone_ could have fixed this or at least hired someone to fix this
years ago (I remember there were kernel patches for "thread-id"
support which were plausible and relatively short). You could have
fixed it on your Linux system. I could have fixed it. Why didn't I?
Because like many I didn't care enough whether getpid() returns a
"process" identifier.
> Whether out of religious
> conviction that they're right and the world is wrong or out of inherently
> selfish desire to limit programmer and user freedom is somewhat irrelevant.
Now as to the kernel developers intentions: there were sound technical
reasons for keeping things simple inside the kernel. Paving the way
for a _completely_ pthreads-conforming userspace just wasn't the
number one priority until recently. Even though your and my
priorities would maybe have been different, the 99% solution that
LinuxThreads presented was and is good enough for lots of people. No
selfishness involved here.
Regards,
Wolfram.
Dragan Cvetkovic
> David Butenhof <David.B...@hp.com> writes:
>
> > NPTL will, eventually, resolve that bug,
>
> nptl is freely available _today_, so if you care enough you can easily
> resolve that bug _now_.
Wolfram. think about Linux as a production system and not as hobby-ist
one. Who is going to run the latest developers kernel in the production?
Hell, many systems still use 2.2 kernel. Until 2.6 kernel becomes available
and the initial bugs there are fixed (remember 2.2.0 and 2.4.0?) NPTL will
not be widespread.
But theoretically you are right.
Wolfram Gloger
> Wolfram. think about Linux as a production system and not as hobby-ist
> one. Who is going to run the latest developers kernel in the production?
> Hell, many systems still use 2.2 kernel. Until 2.6 kernel becomes available
> and the initial bugs there are fixed (remember 2.2.0 and 2.4.0?) NPTL will
> not be widespread.
RedHat already has a backport of all nptl patches for 2.4.x, I'll put
that into production soon :-). I agree that most people shouldn't run
the latest kernel, but for those who are crying for the best possible
standard conformance, I believe it is not too much to ask. Especially
as it is a free upgrade, unlike it would be for the truly proprietary
systems.
Regards,
Wolfram.
Alexander Terekhov
Wolfram Gloger wrote:
[...]
> > Linux developers arrogantly (Microsoftianly?) intended that all users of
> > their software should be forced to do things in THEIR preferred proprietary
> > style rather than using portable standards.
>
> Surely you're joking..
Yeah. Sort of joking. Don't miss "...What's the problem?", "the POSIX
standard is...", and "I refuse to apply stupid patches" bits below.
http://groups.google.com/groups?selm=fa.ib1c3rv.ans2od%40ifi.uio.no
From: Linus Torvalds (torv...@transmeta.com)
Subject: Re: Slow pthread_create() under high load
Newsgroups: fa.linux.kernel
Date: 2000/03/28
In article <2000032801...@xman.org>,
Christopher Smith <x...@xman.org> wrote:
>
>IMHO, at least sharing PIDs would be a useful thing. Signal queues
>would be nice, but there are other ways to deal with that.
I don't understand the pid sharing argument. Just cache the pid of the
parent process, you're done.
Many UNIX implementations do something like this in their getpid()
routine anyway:
static pid_t mypid = 0;
pid_t getpid(void)
{
if (!mypid)
mypid = __getpid();
return mypid;
}
They do it because system calls on most UNIXes are quite slow, and
"getpid()" is used by some (bad) benchmarks to test for system call
speed. Doing it for those reasons is bad.
But the "optimization" in itself is not bad, it's just the _reason_ for
it historically that I dislike. If you take the above code, and add the
code to initialize "mypid" on pthread_create(), then suddenly you have a
(a) faster getpid() (not that it should matter) and (b) it gives you
POSIX behaviour for the subthreads. What's the problem?
Note that the reason the kernel is not POSIX-compliant is:
- the POSIX standard is technically stupid. It's much better to use a
cleaner fundamental threading model and build on top of that.
- things like the above are just so much better and more easily done in
user space anyway.
The reason LinuxThreads has a hard time becoming POSIX-compliant is that
I refuse to apply stupid patches, and a lot of the patches sent to me
have been frankly stupid. They've often implemented pthreads
functionality without any actual thought of how it _could_ be done more
cleanly with a user/kernel split. Again, see above.
Anyway, check out the netscape/mozilla threading library, and the one
from Apache (which I think is based on the mozilla one). They may just
fit your needs..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
regards,
alexander.
David Schwartz
> But this is all silly and pointless semantics.
I honestly don't believe the semantics are silly or pointless. The
definition of "process" is actually important to get straight because
the definition of a "process ID" follows naturally from it.
The Linux developers have maintained the position that they have
because they're convinced that they are right. They believe that
everyone else has dones things wrong in the name of principles and that
their approach is pure as driven snow.
For 'getpid' to not return a process ID is not pure as driven snow.
It's kludgy.
DS
David Schwartz
> Because like many I didn't care enough whether getpid() returns a
> "process" identifier.
Just in case it wasn't clear, this is just an example of what the
"problem" is. Simply creating a process identifier and having 'getpid'
return it, say by modifying 'getpid' to find return the 'P'ID of the
manager thread, would only hide a single symptom.
The problem is that it's awfully difficult to support the SuSv3 concept
of a process on Linux. And, unfortunately, that concept is tied into
many system calls and system behaviors. Not just 'getpid'.
DS
David Butenhof
> David Butenhof wrote:
>
>> But this is all silly and pointless semantics.
>
> I honestly don't believe the semantics are silly or pointless. The
> definition of "process" is actually important to get straight because
> the definition of a "process ID" follows naturally from it.
Look, if Linux obeys POSIX, then "process" is well defined already; no
semantic argument is necessary or relevant. If Linux were to toss aside the
extensive efforts (both technical and policital) of the international
standards bodies that developed POSIX and SUS and go its own proprietary
way with variable weight process interfaces, then its developers can make
up their own minds what they want to call a process, and it doesn't matter
much to me (or maybe to much of anyone else).
> The Linux developers have maintained the position that they have
> because they're convinced that they are right. They believe that
> everyone else has dones things wrong in the name of principles and that
> their approach is pure as driven snow.
"Right" and "wrong" are meaningless terms in this context. Linux pays heed
to some standards to encourage compatibility and migration between various
UNIX family systems and itself, and also to discourage radical divergences
between Linux variants. Life is full of compromises, and nothing's perfect.
I'm certainly not going to argue that POSIX is perfect; but it
(supplemented by SUS, of course) IS the only widely portable international
API standard for "UNIX-like" systems.
Right now, people can write for Linux AND UNIX, shifting between them
depending on their needs. The more Linux shifts away from UNIX, the less
practical that becomes. Eventually, Linux might as well be Windows; you
either write for it, or you write for something else, or you basically
write everything twice. Lots of code is modularized or heavily
conditionalize to work on both Windows and Mac, or Windows and UNIX, or all
of them. But for others, this represents a major barrier.
Right now, I see Linux moving CLOSER to UNIX, both with NPTL, and also with
the LSB (Linux Standards Base) process in the Open Group. I hope that trend
continues rather than having Linux pretending to "do standards" while
actually working to splinter programmers off into its own proprietary
alternatives; as Windows does routinely. ;-)
> For 'getpid' to not return a process ID is not pure as driven snow.
> It's kludgy.
That's silly. It's not "kludgy" for a function to do what it's defined to
do. If you'd like to argue there's no point in having a function to return
the ID of the calling process (or thread), that's an entirely different
issue, and it's not relevant to this particular word game.
It's hard for Linux to return a proper process ID because it doesn't
implement threads. That's why getpid currently (for various definitions of
"currently") returns the ID of a "kernel execution entity" rather than
either a process or a thread.
If the system really implemented processes and threads, this wouldn't be
hard, or kludgy. It's the continued refusal to actually DO that, that makes
it hard or even "unclear".
Alexander Supalov
Standards are created to stop innovation, or so some of us think once in
a while.
Perhaps, it's not that bad that Linux guys stayed true to their original
design decisions until a reasonable solution (i.e., NPTL) was found. I
certainly think that the clone(), etc., with its flexibility is a good
low level system interface. The fact that one can build well performing
POSIX threads on top of it using relatively small changes is another
positive sign.
Their attitude, however, is totally different from that of the Microsoft
as far as I can judge it. Linux guys do know the standards and support
them if they find them good or necessary to support, and if they know
how to do that well. Microsoft sort of disregards whatever is out there
until they've got their very own solution that happens to do it the
other way round.
But even they manage it on the third pass, as a matter of rule. Linux is
making its second earnest as far as POSIX threads go, so I suggest that
we just get off their feet now, and cheer the NPTL team to hone their
stuff to production quality. I'll be very eager to give it a try...
then, for I know from experience how much can happen between promising
tests and a finished product.
Best regards.
Alexander
--
Dr Alexander Supalov
Senior Software Engineer
--------------------------------------------------------------------
//// pallas / A Member of the ExperTeam Group
Pallas GmbH / Hermuelheimer Str. 10 / 50321 Bruehl / Germany
Alexande...@pallas.com / www.pallas.com
Tel +49-2232-1896-34 / Fax +49-2232-1896-29
--------------------------------------------------------------------
David Schwartz
> David Schwartz wrote:
> > David Butenhof wrote:
> >> But this is all silly and pointless semantics.
> > I honestly don't believe the semantics are silly or pointless. The
> > definition of "process" is actually important to get straight because
> > the definition of a "process ID" follows naturally from it.
> Look, if Linux obeys POSIX, then "process" is well defined already; no
> semantic argument is necessary or relevant.
Linux doesn't.
> If Linux were to toss aside the
> extensive efforts (both technical and policital) of the international
> standards bodies that developed POSIX and SUS and go its own proprietary
> way with variable weight process interfaces, then its developers can make
> up their own minds what they want to call a process, and it doesn't matter
> much to me (or maybe to much of anyone else).
Fine, but then they're using the word "process" differently from
everyone else. By using the same word and hiding the difference, they
get to pretend that the problems they've created don't exist.
> Right now, I see Linux moving CLOSER to UNIX, both with NPTL, and also with
> the LSB (Linux Standards Base) process in the Open Group. I hope that trend
> continues rather than having Linux pretending to "do standards" while
> actually working to splinter programmers off into its own proprietary
> alternatives; as Windows does routinely. ;-)
Well, don't you think that stopping them from giving common terms (like
'process') new meanings so that they can masquerade their proprietary
interfaces as standard ones is important?
> > For 'getpid' to not return a process ID is not pure as driven snow.
> > It's kludgy.
> That's silly. It's not "kludgy" for a function to do what it's defined to
> do. If you'd like to argue there's no point in having a function to return
> the ID of the calling process (or thread), that's an entirely different
> issue, and it's not relevant to this particular word game.
Huh? Are you disagreeing with me?
> If the system really implemented processes and threads, this wouldn't be
> hard, or kludgy. It's the continued refusal to actually DO that, that makes
> it hard or even "unclear".
Right. So their defense that they are doing things cleanly and
elegantly is bogus. How can it be clean and elegant for the 'get process
ID' function to not return a process ID?
DS
Alexander Terekhov
David Schwartz wrote:
[...]
> > If the system really implemented processes and threads, this wouldn't be
> > hard, or kludgy. It's the continued refusal to actually DO that, that makes
> > it hard or even "unclear".
>
> Right. So their defense that they are doing things cleanly and
> elegantly is bogus.
As a sort of occasional-observer-from-outside, I'd say that there was no
"defense" other than total ignorance of POSIX threading.
> How can it be clean and elegant for the 'get process
> ID' function to not return a process ID?
I guess, the way of thinking was: it IS totally clean and elegant... as
long as you don't have a threaded process, the POSIX one... which is crap
not worth worrying about.
http://groups.google.com/groups?selm=E15Abr6-00057R-00%40the-village.bc.nu
http://groups.google.com/groups?selm=20010615010557.A3869%40werewolf.able.es
regards,
alexander.
--
http://groups.google.com/groups?selm=linux.kernel.E16UwM8-0002hb-00%40the-village.bc.nu
Alexander Terekhov
Alexander Supalov wrote:
[...]
> we just get off their feet now, and cheer the NPTL team to hone their
> stuff to production quality. I'll be very eager to give it a try...
> then, for I know from experience how much can happen between promising
> tests and a finished product.
http://www.redhat.com/about/presscenter/press/2003/press_rhl9
regards,
alexander. < a bit surprised, so to speak >
Alexander Supalov
> < a bit surprised, so to speak >
They made sure it's stamped March 31, not April 1. However, there's an
interesting note about "forward statements" at the bottom of that page,
and general availability of RedHat 9.0 is scheduled for April 7.
Wolfram Gloger
> The problem is that it's awfully difficult to support the SuSv3 concept
> of a process on Linux. And, unfortunately, that concept is tied into
> many system calls and system behaviors. Not just 'getpid'.
I know, however I can't think of more important examples other than
those related to signal handling (admittedly a sizable chunk of system
behavior). Since I have been faring well with "signals and threads
don't mix well" for a long time, these limitations haven't bothered me
too much, either.
Regards,
Wolfram.
Wolfram Gloger
> Yeah. Sort of joking. Don't miss "...What's the problem?", "the POSIX
> standard is...", and "I refuse to apply stupid patches" bits below.
>
> http://groups.google.com/groups?selm=fa.ib1c3rv.ans2od%40ifi.uio.no
This is clearly written purely from the kernel point of view. Aside
from the "technically stupid" insult (not backed up by any technical
argument), the posting makes sense to me. And in fact, I suspect it
could well be "technically stupid" to develop a kernel which would
have the complete pthreads standard already implemented as system
calls.
Also I wasn't so much objecting to the assertion that Linux doesn't
support the pthreads standard as much as it could, but rather to the
"proprietary" label, which is just ridiculous. If anyone would have
cared enough, she or he could even have forked the kernel just to
drive pthreads conformance to perfection. In fact, I think with ngpt
this fork actually happened. With nptl we now even have successfully
overcome the "stupid patches" stage, and everything seems reconciled.
None of this would have been possible with a proprietary development
model.
Regards,
Wolfram.
Casper H.S. Dik
>None of this would have been possible with a proprietary development
>model.
People seem to be losing track of what proprietary means.
"proprietary" used to be used solely to distinguish "belonging to
a single entity". Open source or closed source does not matter.
E.g., the LGPL interfaces are all proprietary interfaces.
For an interface to be non-proprietary it must have an available
specification and no encumbering for reimplementations; it naturally
follows that there really must be more than one implementation.
(I don't think "clone()" is proprietary by that definition)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Patrick TJ McPhee
David Schwartz <dav...@webmaster.com> wrote:
% David Butenhof wrote:
% > If Linux were to toss aside the
% > extensive efforts (both technical and policital) of the international
% > standards bodies that developed POSIX and SUS and go its own proprietary
% > way with variable weight process interfaces, then its developers can make
% > up their own minds what they want to call a process, and it doesn't matter
% > much to me (or maybe to much of anyone else).
%
% Fine, but then they're using the word "process" differently from
% everyone else. By using the same word and hiding the difference, they
% get to pretend that the problems they've created don't exist.
I think the problem here is that this is going to happen in any case.
The part of the susv3 definition you've quoted previously is not the
entire definition:
3.289 Process
An address space with one or more threads executing within that address
space, and the required system resources for those threads.
Note: Many of the system resources defined by IEEE Std 1003.1-2001 are
shared among all of the threads within a process. These include the
process ID, the parent process ID, process group ID, session
membership, real, effective, and saved set-user-ID, real, effective,
and saved set-group-ID, supplementary group IDs, current working
directory, root directory, file mode creation mask, and file
descriptors.
This is not a complete definition of the characteristics of a process.
It's a definition of the word which gives readers a context in which
they can understand the rest of the standard. susv3 has other
requirements for processes -- signal handling comes to mind because it's
important to me. When dealing with a non-conforming system, the
definition of `process' has to be whatever the system designers want
it to be. People using the system then have a context in which they
can understand and work around the areas of non-conformance.
My point is that, while current Linux systems don't conform to susv3
(or v2 for that matter) when dealing with multi-threaded processes,
your definition of process is even further from susv3, since none
of the important characteristics, such as the process ID, signal
queue, and so forth conform to the standard. This doesn't sound
like common sense to me, it's simply ridiculous.
Gerhard Wesp
> None of this would have been possible with a proprietary development
> model.
What's a ``proprietary development model''?
FYI, many commercial (== proprietary, for some meaning of this word?)
UNIXes *do* implement the standardized threading interface. And they do
it very well.
-Gerhard
--
| voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/
|
| Passts auf, seid's vuasichdig, und lossds eich nix gfoin!
| -- Dr. Kurt Ostbahn
Duke Robillard
> Wolfram Gloger <wm...@dent.med.uni-muenchen.de> wrote:
>
>>None of this would have been possible with a proprietary development
>>model.
>
> What's a ``proprietary development model''?
>
> FYI, many commercial (== proprietary, for some meaning of this word?)
First "process" and now "proprietary." I predict the next
word to be subjected to a heated definitional debate will
be "standard." :-)
Duke
Alexander Terekhov
Wolfram Gloger wrote:
>
> Alexander Terekhov <tere...@web.de> writes:
>
> > Yeah. Sort of joking. Don't miss "...What's the problem?", "the POSIX
> > standard is...", and "I refuse to apply stupid patches" bits below.
> >
> > http://groups.google.com/groups?selm=fa.ib1c3rv.ans2od%40ifi.uio.no
>
> This is clearly written purely from the kernel point of view.
This was clearly written purely from the "script kiddie" point of
view, I'd say.
> Aside
> from the "technically stupid" insult (not backed up by any technical
> argument), the posting makes sense to me. And in fact, I suspect it
> could well be "technically stupid" to develop a kernel which would
> have the complete pthreads standard already implemented as system
> calls.
That's pretty much what Microsoft did. Note that POSIX.1 is the
source code level API standard. As for the "kernel"... a search on
THAT (in the POSIX standard) yields this, for example:
<quote>
posix_spawn() System Interfaces
Threads
Without the posix_spawn() and posix_spawnp() functions, systems
without address translation can still use threads to give an
abstraction of concurrency. In many cases, thread creation suffices,
but it is not always a good substitute. The posix_spawn() and
posix_spawnp() functions are considerably ``heavier'' than thread
creation. Processes have several important attributes that threads
do not. Even without address translation, a process may have base-
and-bound memory protection. Each process has a process environment
including security attributes and file capabilities, and powerful
scheduling attributes. Processes abstract the behavior of non-
uniform-memory-architecture multi-processors better than threads,
and they are more convenient to use for activities that are not
closely linked. The posix_spawn() and posix_spawnp() functions may
not bring support for multiple processes to every configuration.
Process creation is not the only piece of operating system support
required to support multiple processes. The total cost of support
for multiple processes may be quite high in some circumstances.
Existing practice shows that support for multiple processes is
uncommon and threads are common among ``tiny kernels''. There
should, therefore, probably continue to be AEPs for operating
systems with only one process.
</quote>
>
> Also I wasn't so much objecting to the assertion that Linux doesn't
> support the pthreads standard as much as it could, but rather to the
> "proprietary" label, which is just ridiculous.
To me, "proprietary" (in the context of this discussions) doesn't
mean "closed source".
> If anyone would have
> cared enough, she or he could even have forked the kernel just to
> drive pthreads conformance to perfection. In fact, I think with ngpt
> this fork actually happened.
That's NOT true. Well, you might want to do some research on the
topic of "who did what" with respect to things like posix signals,
futexes, and etc.-stuff that is {still} used by the current NPTL.
> With nptl we now even have successfully
> overcome the "stupid patches" stage, and everything seems reconciled.
Except that now (well, starting on the 7th of April, if you like)
we are in the stage of "stupid patches" with respect to kernel AND
NPTL. ;-)
regards,
alexander.
--
http://www.terekhov.de/DESIGN-futex-CV-with-async.cancelable-wait.txt
https://listman.redhat.com/pipermail/phil-list/2003-March/000777.html
https://listman.redhat.com/pipermail/phil-list/2003-March/000793.html
https://listman.redhat.com/pipermail/phil-list/2003-March/000805.html
Alexander Terekhov
Duke Robillard wrote:
>
> Gerhard Wesp wrote:
> > Wolfram Gloger <wm...@dent.med.uni-muenchen.de> wrote:
> >
> >>None of this would have been possible with a proprietary development
> >>model.
> >
> > What's a ``proprietary development model''?
I think that he meant to say "closed source" model. Well, open source
is fine but, unfortunately, there is nothing specific whatsoever to
the "unregulated" open source model that guarantees:
- that stuff will be well designed
- that it will be reviewed by competent people willing to spend
time to discover the flaws
- that maintainers will listen.
> >
> > FYI, many commercial (== proprietary, for some meaning of this word?)
>
> First "process" and now "proprietary." I predict the next
> word to be subjected to a heated definitional debate will
> be "standard." :-)
Well,
http://www.opengroup.org/press/cargill_13sep00.htm
(The Role of Standards in Today's Society and in the Future)
"Stage 1: This is the 'proprietary standard', ...."
regards,
alexander.
Gerhard Wesp
> First "process" and now "proprietary." I predict the next
> word to be subjected to a heated definitional debate will
> be "standard." :-)
Well, I have no intention of heating the discussion. Mine was a genuine
question, because the connotaion of proprietary wasn't (and still isn't)
clear to me in this context. Proprietary as an adjective to interface
for me means an interface which is controlled by a sole maintainer who
can change it at will. Proprietary hardware is hardware with
undocumented interfaces.
And I know of the open and closed source development models. But
proprietary...?
Before *anything* can be discussed, we all should make sure that we
actually understand what the participants mean with their statements! :-)
Duke Robillard
> Duke Robillard <du...@io.com> wrote:
>
>>First "process" and now "proprietary." I predict the next
>>word to be subjected to a heated definitional debate will
>>be "standard." :-)
>
> Well, I have no intention of heating the discussion. Mine was a genuine
> question, because the connotaion of proprietary wasn't (and still isn't)
> clear to me in this context. Proprietary as an adjective to interface
> for me means an interface which is controlled by a sole maintainer who
> can change it at will.
Kinda like Linus did with clone()? :-)
"Proprietary" means "is the property of." It's sort of the opposite
of "public domain" which means "is held in common by everybody."
The GPL stands this definition on its head, which is why its such
a clever bit of work. Oddly enough, it uses copyright to assert
"proprietariness," in order to assure availability to everyone.
It could only have been invented by a CS geek; it's got "meta"
written all over it. :-)
In common useage nowadays, people use "proprietary" to mean "closed
source," or "undocumented," or "available from only one vendor," but
that's not really what it used to mean. Standards people tend to
use it to mean "an API that's not in the standards document" but that's
probably not so good either.
Duke