That makes your performance reminiscent of a PC running DOS.
> That can help in multi-threading a kernel (multiple-thread the
> STREAMS correctly, and the drivers/modules follow - well, almost, yes?).
No
> That can be used to pass data directly between a device's dual-ported
> memory up into user's process. Ah, those lovely 'cloning' devices.
No
> Being able to pass pipes between unrealted processes....
You can do that with sockets
> a few faults, and nasty kludges in some places to make them usable
> as sockets. I cannot agree they are 'too slow'.
All the people who I count as networking experts say streams are much too
slow. People like Van Jacobson: I quote a couple ...
"I agree with your conclusion that STREAMS stink. Anyone who's
measured the code reaches the same conclusion. It's widely
believed that the esigners' of STREAMS were all former COBOL
programmers taken off writing long distance billing programs
for AT&T and ordered to learn C and turn v7 Unix into System-V. "
-- Van Jacobson to Mike Neumann
And Dennis Ritchie on what they did to his elegant v8 streams..
"the idea loses something when it's shouted"
> IMHO, STREAMS do bring a benefit to user space, but the largest
> gain is within the kernel (they make it a much more friendlier place
> to live, and code). Trying emulating them in user space sounds
> strange to me. I guess you were stating that it is theoritically
> possible?
Yes. The kernel's business isnt being a friendly place. The kernel's
business is doing things for user space as fast as is possible as
efficiently as possible. If we wanted it friendly we'd write it in basic 8)
Streams for example has strict layering. The memory subsystem of a modern
machine makes strict layering the wrong approach. Everyone with fast
streams has a stack where if all the modules arent real streams but run in
"cheat" mode as it were use different code paths.
Alan