Re: anyone define port types?

[Andy Wingo <wingo@pobox.com>]

On Thu 23 Jun 2016 00:44, Chris Vine <chris@cvine.freeserve.co.uk> writes:

> I have stirred myself and installed guile-2.1.3.  On looking more at
> the suspendable ports code it became obvious and I haven't needed to
> adopt anything like ethreads with its "thread" abstraction: instead I
> have kept the approach already adopted in the guile-a-sync library.

Excellent.  Though I think that eventually we will want to bless one of
these concurrency patterns as the default one, we're a long way away
from that, and even if we do bless one I think we will always want to
allow people to experiment and deploy different ones.  So, great, glad
to hear you are doing work in this area :)

> However, the consequence of using suspendable ports instead of C ports
> is that the await-getline! procedure (as an example) has been reduced
> to a mere 16 lines of code, mainly because it is possible to use (ice-9
> rdelim)'s read-line procedure with non-blocking ports.

Excellent!  That's the result I was hoping for.

> I have made a new repository for guile-a-sync for use with guile-2.2 and
> when I am happy with the new interfaces (and assuming nothing else goes
> wrong) I will put it up on github.
>
> This is very nice.  Thanks for taking the time to go through it with me.

Thank you for your patience too!

The only drawback that I know of with the strategy of simply allowing
users to use Guile's I/O primitives (e.g., `read-line') and assuming
that they'll suspend when they block is that not all of the primitives
that you would like to you have been rebased on top of the ones
implemented by (ice-9 suspendable-ports).  So if you find such an I/O
procedure that needs to be rewritten to use put-string instead of
display, for example, then please do send a patch.

As for `display' and `write'... I guess we can at least make suspendable
ports handle these in a non-blocking way for some limited number of data
types like strings, characters, and symbols, and dispatch to the C
`display' implementation for more complicated data types like SMOBs or
so.  We'll see I guess.

Happy hacking,

Andy