Re: [Chicken-users] Asynchronous I/O Egg Release

[Chris Vine]

On Thu, 30 Jun 2016 15:39:43 -0400
John Cowan <address@hidden> wrote:
> Chris Vine scripsit:
> 
> > The same effect can be achieved with other ports using
> > thread-wait-for-i/o!, which although blocking also yields and only
> > resumes when there is something available to read.  I don't have a
> > problem with that: you just need to go with it.  And that is what
> > the original poster's egg should be using.  
> 
> Is there some reason why this isn't the default mode?  It seems to me
> that what we want is for all standard Scheme operations to block the
> thread that invokes them and no other threads, so that the programming
> model is synchronous I/O (as RnRS demands) but threads still "work".
> Disk operations aren't exactly instantaneous either, and shouldn't
> block other threads that may be doing computations.

On the first point I agree.  It is definitely the way to do it.  But it
is work to be done and I am not a chicken developer and it is not for
me to demand it.  Chicken developers might take the view that because
files on the file system cannot block, and having provided
thread-wait-for-i/o! for non-sockets which might, it is not worth the
effort given other work that needs to be done.  Having said that, if the
work has been done for sockets it shouldn't be that difficult to
translate it to other file descriptors which might block.  But it is for
those who do the work to take a view.

On the last point ("Disk operations aren't exactly instantaneous
either, and shouldn't block other threads that may be doing
computations"), they _are_ instantaneous for this purpose (but only for
this purpose).  File descriptors for files on the file system always
report themselves as ready, because they can't block.  The "green"
thread implementation has no special knowledge about how long fetching
from the particular file storage medium in question may actually take.
It can just go about its normal pre-emptive scheduling activity.
Possibly the scheduler could have a policy of doing a context switch
every time a read or write operation from disk is made.  I have no idea
whether that is a good idea, but it seems rather extreme.  It is also a
completely different point from the one in this series of postings.

> Providing asynchronous I/O to the user is a completely different
> thing. I personally wouldn't want to use it, but I know there are
> reasons why some people would.

The egg doesn't actually provide asynchronous i/o to the user.  It
attempts to get round the problem of jamming descriptors.

Chris