thoughts on ports

[Andy Wingo <wingo@pobox.com>]

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/