On Wed 06 Jul 2016 19:29, Amirouche Boubekki <amirou...@hypermove.net> 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 <amirou...@hypermove.net> 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