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
_______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
