Re: thoughts on ports

[Andy Wingo <wingo@pobox.com>]

On Fri 18 Jan 2013 22:27, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>> As a thought experiment, I don't see why things should have to slow
>> down.  Master has `scm_c_take_gc_bytevector', which can be used to wrap
>> the existing scm_t_port::write_buf, ::read_buf, and ::putback_buf
>> members.  At the cost of three allocations per port and three words per
>> allocation (bytevector tag, length, and pointer), we could give access
>> to these internal buffers to Scheme without affecting the C code at all.
>>
>> We could go farther and allocate the buffers as bytevectors directly,
>> which would entail an additional indirection for C to get at the length
>> and data, but the length and data would all be contiguous anyway so in
>> practice I don't see it being too bad.
>
> Yes, that seems doable.  What was the initial goal already?

The goal was to be able to provide Scheme functions that operate on
ports, but that can suspend the operation via an abort-to-prompt if it
will block.  This can only be done if we are not recursing through C.
Exposing the fundamental buffers lets port operations to be implemented
in Scheme (while also allowing the C implementation).

Andy
-- 
http://wingolog.org/