| Re: [jetty-dev] Reactive Streams |
Hi,
On Wed, Jun 3, 2015 at 3:46 AM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
>
> Simone,
>
> yep I'm understanding it better now. If you work with the standard RS
> APIs, you can be asynchronous and non-queuing, but only if you give up on
> recyclable items. You can have recyclable items, but then have to give up
> either on asynchronous or non-queuing. You can have all three: async,
> bounded memory & recycling.
No, I disagree :)
You can be recycling provided you pass the right T.
So far we have conflated 2 meanings to our Callback.succeeded():
1) We are done with this buffer, then can be recycled.
2) We are done with this buffer, then we can process another.
This is evident, for example in every implementation of
IteratingCallback: we are overriding IteratingCallback.succeeded() to
"clean up" things, and then we call super.succeeded().
The "clean up" typically involves recycling the buffer we have stored
during process().
With the RS APIs, we only have an explicit 2) above semantic, but not 1).
However:
class PooledBuffer {
private final ByteBufferPool pool;
private final ByteBuffer buffer;
public void complete() { pool.release(buffer); }
}
void onNext(PooledBuffer pooled) {
write(pooled.buffer, new Callback() {
public void succeeded() {
pooled.complete();
subscription.request(1);
}
});
}
You can now argue that you have to allocate the per-PooledBuffer
Callback, but that is only easily resolvable by either having
PooledBuffer implement Callback or by having write() using
PooledBuffers.
Again, I don't think the RS APIs impose some inefficiency per-se.
It may perhaps impose some change to the types we use (for example
there is extensive use, in the current Jetty codebase, of a type that
wraps a Buffer and a Callback) to be efficient, but I don't see any
blocker.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.