Completion ports are not likely to ever be POSIX. Hence we should
first evaluate a lightweight solution based on threads before
implementing completion ports. If the threads solution is shown to be
unsatisfactory, only then does it make sense to look further.
> > > If one really need to use threads, then, one of the following is true,
> > > in my opinion:
> > > - One likes complexity since one is stupid as most programmers.
> > > - One's O/S handles processes as bloat entities.
> > > - One has heared too much O/S 2 lovers.
> > > - One is believing that MicroSoft-BASIC is multi-threaded.
> >
> > Wow! This is really arrogant!
>
> Nothing arrogant here, only kindness. The thread-mania started with OS2
> and I have had to deal for years with people who claim that threads are
> fine since you can use 1 thread to read the keyboard and another thread
> to send data to the printer. No need to use an O/S for such a construct,
> doing I/O directly from the hardware is easier to me.
> OS2 did not have completion nor real signals, so you had to use threads
> if you wanted to be asynchronous. BTW, no need to kill a dead O/S.
> About the thread-oriented Win/NT which is a 32 bit hardwired O/S that
> has been invented once 32 bit architectures has become obsolete, I could
> tell some other kindnesses, too ... What about the ridiculous 32 bit
> port to Alpha? The thread-mania that does bloat UNIX systems comes
> from these brain-deaded things.
It's arrogant because when someone proposes a solution based on
threads, you belittle the whole idea (and by implication, the
person). Instead, you should first evaluate the idea on it's merits. I
may well be that a clever solution based on threads will work very
well. If my userspace solution doesn't perform well, then I'll
advocate (and maybe even implement) completion ports. But I first want
to see how far we can go without departing from UNIX.
> Microsoft guys are modern alchemists who are able to make gold from sh*t.
> Gold is for them, sh*t is for us. :-)
I have no interst in what M$ does in their OS. They are already a step
behind the UNIX world, two steps behind Linux, and we are widening the
gap.
> > > There is probably lots of OS2 multi-threaded programs that can only be
> > > broken on SMP, since I often heared OS2 multi-braindeaded programmers
> > > assuming that threads inside a process are only preempted when
> > > they call a system service.
> >
> > I don't see what this has to do with real threads on a real Unix.
>
> When I see a > 5 MB kernel image, I donnot beleive it is a real UNIX.
> I have the impression that recent UNIXen try to look like some
> proprietary O/Ses and POSIX extensions to UNIX services lead to
> BLOATIX, IMO.
So Linux is bloatware? After all, it has threads.
And I still don't see the relevance of your kernel-bashing
arguments. I'm proposing a wholly userspace solution. Hence it
requires no extra kernel code. Unlike completion ports, I might add...
> > > I have written and maintained lots of application programs under VMS,
> > > UNIX, some have been ported to a dozen of O/S, none of them uses threads.
> > > I donnot envision to use multi-threads in application software and I
> > > donnot want to have to deal with applications that uses this, for the
> > > simple reasons that threads semantics differs too much between operating
> > > systems and that application programs are often large programs that
> > > donnot follow the high level of quality of O/S softwares.
> >
> > Threads have their uses. Sure, they can be abused. So what?
>
> I agree with you that threads have their uses, but it seems to me that
> programmers want to use them even if it is not needed.
Well, I'm not one to jump to using threads just for the hell of
it. Why not read the proposal carefully before jumping up and saying a
threads-based solution is flawed? See:
http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html
> > > Traditionnal UNIXes used light processes and preferently blocking I/Os.
> > > Signals were preferently for error conditions.
> > > The select() semantic has been a hack that has been very usefull for
> > > implementing event-driven applications using a low number of fds, as
> > > the X Server. Trying to use such a semantic to deal with thousands of
> > > handles can only lead to performance problems. This is trivial.
> >
> > A lightweight userspace solution that uses a modest number of threads
> > is cabable of giving us a fast and scalable mechanism for handling
> > very large numbers of FDs. And it can do this without changing one
> > line of kernel code.
> > Independently, we can optimise the kernel to speed up select(2) and
> > poll(2) so that both this userspace library as well as other Unix
> > programmes benefit.
>
> select() and poll() are slow by design, at least in user-land.
> Existing programs will get benefits, but this is not a long term
> solution. The right solution is an asynchronous completion mechanism
> as DEC O/Ses are offering since more than 20 years.
The right solution is one that works with minimal departure from the
UNIX interface. If completion ports provide no measurable performance
advantage over a userspace solution, there is no point to implementing
completion ports. We want compatibility with the UNIX world, not with
VMS.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu