Hi, You are arguing for new I/O primitives with different semantics, and that's fine and good :) My goal was to add the ability to sensibly work with non-blocking ports using Guile's existing primitives, especially the textual ones.
This effort was started because of the ethreads work I did about four years ago. That required a separate implementation of buffered ports, which is fine for a library but not good for a system. You want to be able to set a non-blocking port as the current input port, for example, and you want to be able to (display x p) where p is a non-blocking port, and you want to be able to do this both in a blocking way, because Guile doesn't currently include any kind of user-space scheduler, but also you want to support experiments to make a user-space scheduler. The ethreads work from four years ago also required me to patch various parts of Guile, like the web server, so that they could use different primitives. That's what I want to avoid. I want to be able to run an SSAX parser or a Scheme reader or writer over a non-blocking port and have it just work. (For SSAX it's close to working; there are a couple of primitives that need to be reimplemented in terms of the subset of port interfaces that suspendable ports replaces. For Scheme `read'/`write' the situation is more complicated.) On Sun 19 Jun 2016 11:55, Marko Rauhamaa <ma...@pacujo.net> writes: > Guile's POSIX support provides immediate access to most OS facilities. > However, support for read(2) and write(2) seem to be missing. (Note that > Python, for example, provides both buffered, native facilities and the > low-level os.read() and os.write().) A read operation is supported via `get-bytevector-some', but it's true that `put-bytevector-some' is not implemented. Incidentally, have you seen ljsyscall, for LuaJIT? What a great library. I wish we had something like that for Guile. > I haven't thought it through if that callback paradigm would offer the > same degrees of freedom as the return-whatever-you-have paradigm. It > seems unnecessarily complicated, though. There is complication, but it is necessary complication. If you want to support blocking textual operations with all of the encodings that Guile supports over non-blocking ports, you need to be able to poll() when you get EAGAIN; and if you also want to be able to suspend in the middle of writing a byte sequence, many levels removed from the original write, then you need a parameter; and if you don't know yet the entire set of things you might want to do, that parameter better be a procedure. In practice I find it a delight to work with this interface. See the memcached server and client implementations in the recently updated wip-ethreads branch; to my eye they are lovely. Andy