[Top][All Lists]

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

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

From: Robert Smiley
Subject: Re: [Chicken-users] Asynchronous I/O Egg Release
Date: Thu, 30 Jun 2016 12:14:00 -0600

Hi guys. I'm not very familiar with the low level details, but the documentation for srfi-18 found here.

Contains this quote

"Blocking I/O will block all threads, except for some socket operations (see the section about the tcp unit). An exception is the read-eval-print loop on UNIX platforms: waiting for input will not block other threads, provided the current input port reads input from a console."

When I try running the following code:

(use srfi-18)

(define var 0)
(define thread (make-thread (lambda () (let loop ()
                                           (set! var (add1 var))
(thread-start! thread)
(print var)

No matter how long I wait before hitting enter, result printed is always 0. Although I'm fairly inexperienced, I believe this means that the thread is not running, due to chicken blocking on the call to read-line as it waits for my input. The thread is never run, and never increments var.

As for the library busy waiting, yes I suppose it does. The procedures reader-ready? and writer-ready? use file-select with a timeout of 0 from the posix unit under the hood. thread-wait-for-i/o! or file-select could be used instead of these procedures to allow a thread or the entire process to not busy wait. I was thinking of use cases such as games, where there is work to be done, regardless of weather a client is currently communicating, in which case it might be better to periodically check if input or output is ready, and if not, do something else. Is there a better way to handle those cases than busy waiting?

As I said, I'm fairly inexperienced and would appreciate any feedback you have to offer.


On Thu, Jun 30, 2016 at 11:18 AM, Peter Bex <address@hidden> wrote:
On Thu, Jun 30, 2016 at 04:11:57PM +0100, Chris Vine wrote:
> On Thu, 30 Jun 2016 16:24:52 +0200
> > 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.

Dammit, you're right!  I had no idea, sorry for being so dense.
I've created for this.

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

Indeed, and that is certainly a bug!

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

No, I realise completely.  I was just confused as to what you were
saying.  For some reason I never ran into this, and this hasn't been
reported before (by my knowledge).

But AFAIK the manual states that all ports are nonblocking, or am I just
too confused right now?


Chicken-users mailing list

reply via email to

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