Yes, there is a reason.
Windows does not play like a good little child when it comes to I/O, particularly when it comes to anything even remotely resembling threading. No, there is not a trivial fix. There is nothing approaching a trivial fix. This has been something I've been looking at, off-and-on, for several years. I am currently working on this problem for real and the overhauled ports will (hopefully) be in chicken 5, pending approval. The wall has many head-shaped dents, but it's finally getting somewhere. -elf On Sun, 17 Jul 2016, Robert Smiley wrote:
Date: Sun, 17 Jul 2016 21:48:19 From: Robert Smiley <[email protected]> To: [email protected] Subject: [Chicken-hackers] srfi-18 and blocking i/o Hi everyone. I wrote some I/O routines to get around the following problem documented in the srfi-18 section of the manual on the wiki. "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." Some people commented on chicken-users when I released the library that it would be nice to not have all threads block in core due to i/o. Having taken a look at library.scm, I was wondering if this could be addressed by modifying the read and write procedures of the streaming port class to call ##sys#thread-block-for-i/o! from scheduler.scm. I'm also curious if there is a good reason why ports were implemented in that way in the first place, as it looks like effort has been put into bypassing this issue in certain cases (sockets and the unix repl). Cheers, -Robert
_______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
_______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
