> Gerard Roudier writes:
> >
> > Using multi-threading into a single process context is, IMO, just
> > importing into user-land kernel-like problems and providing such
> > a feature complexifies significantly the involved kernel.
> > Multi-threading into processes is not the way to go, IMO, especially
> > if you want to be portable across platforms.
>
> I'm proposing a userspace abstraction that, on Unix systems, uses
> select(2)/poll(2) and a modest number of threads. It could be ported
> to another OS which has completion ports, if you cared.
If I have completion, then I donnot need threads at all.
> > 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.
Microsoft guys are modern alchemists who are able to make gold from sh*t.
Gold is for them, sh*t is for us. :-)
> > 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.
> > 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.
> > 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.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu