Re: [Chicken-users] Asynchronous I/O Egg Release

[Peter Bex]

On Thu, Jun 30, 2016 at 03:13:17PM +0100, Chris Vine wrote:
> On Thu, 30 Jun 2016 15:22:41 +0200
> Peter Bex <address@hidden> wrote:
> > On Thu, Jun 30, 2016 at 02:10:41PM +0100, Chris Vine wrote:
> > > Then consider it a bug.  Only sockets from the tcp unit operate in
> > > that way, up to chicken-4.10 at least.  For other descriptors you
> > > have to use chicken's srfi-18 extension, namely
> > > thread-wait-for-i/o!.  
> > 
> > Can you produce an example program which doesn't behave as expected?
> 
> As who is expecting?  It's in the documentation.

Which part of the documentation?  Anything that returns a port should
return a nonblocking port.

The OP (IIUC) states that this doesn't happen automatically for anything
but the TCP unit's sockets, which is incorrect AFAICT.  Any port created
by the system's core procedures should be nonblocking.

> As I said, to make this work you have to use thread-wait-for-i/o!

This a reasonably low-level procedure that you should only need to
call when writing your own procedures that use file descriptors.  When
you are using ports, this should be done automatically, in all cases.

> ;;;;;;;;;;;;;;;;;;;
> 
> (require-extension posix srfi-18)
> 
> (let-values (((in out) (create-pipe)))
>   (let ((port (open-input-file* in)))
>     (thread-start!
>      (make-thread
>       (lambda ()
>         (let loop ()
>           (display (read-char port))
>           (loop))))))
>   (let ((port (open-output-file* out)))
>     (let loop ()
>       (let ((cur-time (time->seconds (current-time))))
>         (thread-sleep! (seconds->time (+ cur-time 2)))
>         (write-char #\x port)
>         (flush-output port)
>         (loop)))))

This is considered a low-level use, considering you are creating a port
manually from a file descriptor.  You're right that it's expected that
you have to do this here, though one could argue that open-input-file*
and open-output-file* should really be marking the file descriptor as
nonblocking, but I think that would be considered too intrusive.

Finally, there's also this bug:
https://bugs.call-cc.org/ticket/1134

Cheers,
Peter

signature.asc
Description: Digital signature