[R6RS] I/O <-> GC question

[William D Clinger]

> Now, for an I/O buffer it may be desirable that it remains stationary
> in memory so that an asynchronous OS I/O API (such as that of Windows)
> can read or write data from it behind the scenes.  So it seems it
> would be nice if I/O buffers are special in the sense that they don't
> get moved by the GC.

I think you're worrying about things at too low a level.  Why does
this abstraction have to leak out of the port abstraction?  I know
that the R6RS port abstraction is too weak, but shouldn't that be
fixable by strengthening the port abstraction instead of by adding
new abstractions?

If the "byte vector" were sealed inside the port abstraction, as in
the R5RS, then implementations would have the freedom necessary to
lock it down or to allocate it and to collect it however they wish.
If you let that "byte vector" leak out of the port abstraction,
implementations will lose this freedom, making them less efficient.

> I'm wondering what impact this has on the API---is it sufficient to
> offer something like MAKE-I/O-BUFFER-BYTE-VECTOR, where the objects it
> creates are still regular byte vectors from the program perspective
> (i.e. they answer true to the same predicate, and the same procedures
> work on them as for regular byte vectors), or is a completely disjoint
> type necessary?

Glarg.  An I/O buffer is more than a byte vector.  What's next, raw
char* pointers into byte vectors?

Will