[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ann] fibers 0.1.0

From: Andy Wingo
Subject: Re: [ann] fibers 0.1.0
Date: Thu, 07 Jul 2016 12:07:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]