Re: [Chicken-hackers] srfi-18 and blocking i/o

[Elf]

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 <address@hidden>
> To: address@hidden
> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/chicken-hackers