chicken-users
[Top][All Lists]
Advanced

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

[Chicken-users] Update to async-io Egg and More on Blocking I/O


From: Robert Smiley
Subject: [Chicken-users] Update to async-io Egg and More on Blocking I/O
Date: Fri, 1 Jul 2016 14:28:46 -0600

Hello everyone. Quite an interesting discussion started in response to my announcement of the async-io egg the other day. I've been following along and Chris Vine had made some mention of busy waiting being a flaw with the library itself. He mentioned that this could be dealt with using thread-wait-for-i/o!

I thought this was a good idea, so I've incorporated two new procedures into the egg: thread-wait-for-reader! and thread-wait-for-writer!. These are very simple wrappers around thread-wait-for-i/o! so that users may suspend the current thread until a reader or writer is ready to be used. This way a user will not need to import the posix library and retrieve the underlying file descriptor from a reader or writer do do this.

Documentation for the egg is now available on the wiki:
http://wiki.call-cc.org/eggref/4/async-io

Chris also mentioned that thread-wait-for-i/o! could be used to avoid having a thread block when using the normal chicken i/o procedures (sorry if I'm wrong, I think that is what you meant). The thread would yield and not be scheduled again until the underlying file descriptor is ready for read or write operations.

My concern with this would be with procedures such as read. read does not return whatever is immediately available from an input file, but the next s-_expression_.

Let's say that we call thread-wait-for-i/o! so that our thread suspends until input is available.

Next, for some reason, a process communicating with our application only writes a partial s-_expression_ to a pipe, such as "(+ 1".

This means input will be available on our file descriptor, resulting in our thread being scheduled again.

Our application calls read, but there is not a full s-_expression_ available, so our application blocks until the other program writes the rest of the _expression_. Something like " 1)".

This is why I thought an asynchronous reader, which simply takes whatever is immediately available and buffers it until a full _expression_ is available would be a good idea.

There was also a lot of talk about why chicken's normal i/o procedures block all threads unless we are performing them on sockets. This problem is the reason why I wrote this egg in the first place. If it is an issue for a lot of people though, maybe we should put in a feature request and see if this can be changed in a future release?

-Cheers,
Robert

reply via email to

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