4 ms·
This sounds a lot like the "discipline and method" approach taken by David Korn, Kiem-Phong Vo and Glenn Fowler in SFIO (http://www2.research.att.com/~gsf/downl
by bediger 15y ago
This sounds a lot like the "discipline and method" approach taken by David Korn, Kiem-Phong Vo and Glenn Fowler in SFIO (http://www2.research.att.com/~gsf/download/ref/sfio/sfio.html http://www2.research.att.com/~gsf/download/ref/sfio/sfio.htm...), vmalloc (http://www2.research.att.com/~gsf/download/ref/vmalloc/vmalloc.html http://www2.research.att.com/~gsf/download/ref/vmalloc/vmall...), and Cdt (http://www2.research.att.com/~gsf/download/ref/cdt/cdt.html http://www2.research.att.com/~gsf/download/ref/cdt/cdt.html)
- psykotic 15y agoReading the Usenix paper on SFIO, I don't see much of a resemblance, beyond what you'd expect to find between stream abstractions in general. The really cool thing about Fabian's streams is that the producer (and ultimately the dynamic structure of the underlying data) dictates how the stream is buffered, with little to no inconvenience to the consumer. SFIO's direct stream buffer access with sfreserve() is more like a traditional stream abstraction that you'd find in Java. It's true that sfreserve() has the producer reserve the memory, which means you can eliminate some memory copying when you're stacking streams, but the consumer is still dictating the size of the buffer.