[Top][All Lists]

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

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

From: Peter Bex
Subject: Re: [Chicken-users] Asynchronous I/O Egg Release
Date: Thu, 30 Jun 2016 16:24:52 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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:


Attachment: signature.asc
Description: Digital signature

reply via email to

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