Re: Thread deficiencies
On Fri, 7 Jan 2000 tytso@mit.edu wrote:
> Date: Fri, 07 Jan 2000 00:13:22 -0500
> From: Al Guerra <mclinux@gate.net>
>
> No. Firstly, we are not the POSIX standards body. We are the __Linux__
> standards body. Any pretense of being all things to everyone should be
> dropped right now. Developers that want to write Linux apps will have to
> use what Linux provides. Linux doesn't have pthreads, it has clone(). So
> we should adopt clone().
>
> Umm... but part of our purpose is to encourage the development and
> porting of already existing Unix applications by third-party software
> vendors (ISV's) to Linux. The attitude of "tough shit if your program
> which took ten man-years to development uses Posix Threads" isn't hardly
> calculated to encourage those ISV's to port their product Linux.
>
> If you will recall, a long time ago, back in the Linux kernel 0.10 days,
> Linus explained that when he found a portability problem with an
> application, if the issue was with POSIX.1 compliance, he would fix the
> kernel instead of modifying the application. That's what got us to
> where we are today. Telling people to screw standards and use a linux
> specific interface might be what we have to do in the short-run, but I
> don't think it works for the long-term.
>
> - Ted
I don't think it was part of our mandate to provide every software tool
ISV developers could possibly use. I thought it was more to provide a
(minimal) set of features that vendor could count on being there.
We are mandated with taking existing specification where we can and
documenting existing practice where no standard exists, but there is a
prevailing practice in the Linux community. From the discussion I have
heard the existing practice is clone, and there is no existing
functional threads API/ABI in existance for Linux.
This tells me we _can_ specify a clean clone interface and provide that
functionality. The fact that existing "big apps" use their own threads
code indicates that it really isn't an impediment to writing such apps,
and does not necessarily require a specification. Waiting to include
functionality in a specification, until it becomes mature, is not any kind
of "screw standards" attitude.
If a "critical" interface standard is not provided by the LSB, then the
interface used is completely up to the vendor, with the understanding that
it be handled local/static/internal to the vendor's package. Our job is to
provide as much useful interface as we can without creating new
development projects.
While I can appreciate that threads are important/critical from several
points of view, I don't see anything coming out of this discussion that
convinces me there is any way to include a viable thread specification in
the LSB-1.0 specification. What the future holds is another matter, and
once there truely _is_ a viable thread specification in existance, then
LSB should certainly include it.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Reply to: