Hi guys. I'm not very familiar with the low level details, but the documentation for srfi-18 found here.
https://wiki.call-cc.org/man/4/Unit%20srfi-18 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)) (loop))))) (thread-start! thread) (read-line) (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. -Robert On Thu, Jun 30, 2016 at 11:18 AM, Peter Bex <[email protected]> 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 https://bugs.call-cc.org/ticket/1303 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? > > Cheers, > Peter > > _______________________________________________ > Chicken-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/chicken-users > >
_______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
