Hi all, I have been thinking about ports recently. I know other folks have had some thoughts here too, so it's probably good to have a discussion about how they should look.
I'm coming from the perspective of the recent (ice-9 eports) work on wip-ethreads. I found that it's fun and useful to be able to implement ports in Scheme. Fun, because it's Scheme; and useful, because you can block via saving the (composable) continuation, adding to a poll loop, and rescheduling. There are also some potential optimizations when you implement ports things in Scheme because for most users, who program in Scheme, you cut out some layers. It turns out that (ice-9 eports) don't actually have anything to do with events, in the end -- having added a simple abstraction for read/write/close operations, there is no fd-specific code in the eports stuff. Eports are more about efficiently and flexibly handling binary input and output, with appropriate buffering. That starts to raise the question of what the relationship of (ice-9 eports) is with our ports implemented in C (let's call them "cports"), and the panoply of interfaces implemented for cports. Obviously we need ports implemented in C because of bootstrapping concerns. But can we give Scheme access to buffering and the underlying fill (read) / drain (write) / wait (select) operations? So, the idea: refactor the port buffers (read, write, putback) to be Scheme bytevectors, and internally store offsets instead of pointers. Give access to some internal port primitives to a new (ice-9 ports) module. I think we can manage to make (ice-9 ports) operate in both binary and textual modes without a problem, just as we do with cports. We'll have to expose some iconv primitives to (ice-9 ports), but that's just as well. (Perhaps we should supply an (ice-9 iconv) module ?) This is also our chance to modularize the ports code. We can add module autoloads to load up less-frequently-used parts of the ports interface on demand. Anyway, that's my current thought. Again, the advantages: fewer layers between Scheme and I/O, modularization, and the ability to suspend blocking operations in user-space rather than kernel-space. Thoughts? Cheers, Andy -- http://wingolog.org/
