Re: [ann] fibers 0.1.0

[Andy Wingo]

On Wed 06 Jul 2016 19:29, Amirouche Boubekki <address@hidden> writes:

> (Resent the mail to the mailing list)

Resending my reply, I didn't notice it was a private message.  (Please
don't send me private messages about Guile; always send to the list.)

On Tue 05 Jul 2016 21:16, Amirouche Boubekki <address@hidden> writes:

> It's ok to use several put-* procedure instead of one? For example:
>
> ```
> (put-string port "abc")
> ```
>
> is not better than
>
> (put-char port #\a)
> (put-char port #\b)
> (put-char port #\c)

put-string is better performance-wise than multiple put-char
invocations.  But you should check :)

> Otherwise said (?) is there still buffering when using non blocking
> sockets?

Guile sockets are unbuffered by default but that can be changed by
calling `setvbuf' on them.

> Does (web client) http-get work vanilla when the fiber is running?

It should work, yes.  The problem would come in only if it uses I/O
primitives that haven't been expressed in terms of the low-level
non-blocking I/O primitives.  That would be a suspendable-ports bug.  In
that case some I/O operations would actually block instead of running
properly asynchronously.  That's the case for example if you do

  (display "foo" port)

Display hasn't been rewritten in Scheme yet, so it uses C internally and
the C ports code won't suspend; it will block.  We need to either change
uses of `display' to use put-string / put-char, or reimplement `display'
in scheme.  The latter is hard but it's possible to incrementally
reimplement `display', where for example `display' on a string will use
put-string, but on anything else dispatches to C.

Andy