Opps. Maybe not into user-space! But they do allow such memory to be
passed all the way to the stream-head. OK, you can do similar (better?)
with other methods, but I found using a release pointer for a data
block flexible.
> 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"
There is no way I can disagree, or would want to disagree, with names
like that. I've learnt something.
>> 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)
Would that be M$'s Visual Basic? :)
I found STREAMS a v. good service for what we were trying to do. If
we were trying to pump data down an FDDI at 100Mbips, maybe we would
have found the implementation/design lacking - I don't know.
STREAMS allowed us to concentrate more on the ISDN protocol, rather than
worrying about a lot of other details. We also got some good debug
support from the service (a God send!). Not every line of code in
the kernel needs to be optimised down to the last cycle (although in
an idea world, it would), __sometimes__ a working implementation is
better than no implementation (this last line sounds like flame bait,
please note the underlining of 'sometimes').
> 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.
I though STREAMS managed to avoid a lot of memory copies, and uses
caches of common objects/data sizes to speed up allocation. It is
also possible to pass a message 'over' a 'layer'.
Maybe I've misunderstood your point...
Regards,
markhe