> 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:
>
> status = sys$qio(
> READ_OPCODE, fd, buffer, sizeof(buffer),
> <lots of other parameters that I've long since forgotten>,
> ast_function, ast_parameter, ...);
>
> The read would get posted, and when complete the ast_function would
> get called with the ast_parameter in the context of the process that
> posted the QIO. This provided a powerful and easy-to-use method of
> dealing with async IO. It's one of the few VMS features that I wish
> Unix supported.
RSX and friends (IAS, ...) already had such a feature.
With such a mechanism, application programs get IO completion (software)
interrupt as the kernel get completion interrupt from the hardware.
DEC O/Ses have had AST mechanisms for years without offering threads.
Speaking about VMS, you can pass data (or event) using interlocked
queues between AST and process and between processes using shared
memory and so you donnot need to use critical sections for synchonizing
data or event passing. No need to use several threads sharing a process
address space to make things rights.
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.
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.
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 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.
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.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu