Open schveiguy opened 2 weeks ago
Returning "would block" is not enough. We also need a mechanism to register the source into a system to wait for it to be ready.
This mechanism would have to be done via some kind of valve, or maybe a new abstraction.
So maybe a waitHandle
property or whatnot, that gives the thing that can be used to wait on. In the case of an io object, it would return the typed handle of the io primitive (like a File or a Socket).
How to wait on that handle is not going to be defined by iopipe. iopipe is only concerned with processing the data with a buffer, not how the source works.
It has become increasingly obvious that fiber-based i/o will not cut it for async in D.
Given that, we need an explicit mechanism to do async i/o in iopipe.
I think all that is needed is to update extend to return a specific value when it cannot read more data, but that the underlying source is not done.
A preliminary/obvious API is to return size_t.max in this case.
Another possibility is to define an alternative extend mechanism, such as
extendAsync
. This gets complex, however, as every iopipe now has to define both extend and extendAsync, depending on the underlying iopipe support.