Re: Thread implementations...

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Mon, 22 Jun 1998 09:36:02 +1000

Gerard Roudier writes:
>
> On Sun, 21 Jun 1998, John Kodis wrote:
>
> > On Sat, Jun 20, 1998 at 01:49:50PM -0700, Dean Gaudet wrote:
> >
> > > - let the kernel queue an event when the FD becomes ready. So rather than
> > > calling poll() with a list of 100s of FDs, we tell the kernel on a per-FD
> > > basis "when this is ready for read/write queue an event on this pipe, and
> > > could you please hand me back this void * with it? thanks".
> >
> > Yow! Shades of VMS! This sounds very much like the VMS Async System
> > Trap mechanism that allowed you to perform a queued IO operation using
> > a call something like:
[...]
> 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 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!

> 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.

> 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?

> 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.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu