chicken-users
[Top][All Lists]
Advanced

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

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


From: Chris Vine
Subject: Re: [Chicken-users] Asynchronous I/O Egg Release
Date: Thu, 30 Jun 2016 16:11:57 +0100

On Thu, 30 Jun 2016 16:24:52 +0200
Peter Bex <address@hidden> wrote:
> 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.

I think you are wrong.  On my limited testing it happens with chicken if
you use R5RS's open-input-file on any file which is not on the file
system, such as "/dev/tty".  open-input-file is on any basis part of
the system's core procedures.  And of course, reads of files on the file
system never block at all: they just return end-of-file when the end is
reached, so the issue doesn't arise with them in the first place.

> > 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.

It appears not.

> > ;;;;;;;;;;;;;;;;;;;
> > 
> > (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.

Obviously you can always win if any use other than opening a file on the
file system (which never blocks anyway) or opening a socket (for which
chicken makes special provision) is considered "a low level use".
However, that just means you are agreeing with what I and the original
poster said, maybe without realising it.

Chris



reply via email to

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