On 10/30/2015 11:24 PM, Mandy Chung wrote:
On Oct 30, 2015, at 3:38 PM, David M. Lloyd <david.ll...@redhat.com> wrote:
(that's what I was looking for before), or maybe even ToIntFunction<X> where X is
something that might inform the next batch size based on the work that has already been
done - maybe even a Stream<StackFrame> that consists only of the current batch?
Or another idea:
<T> T walk(BiFunction<Stream<StackWalker.StackFrame>, IntConsumer, T>
function);
where the IntConsumer can be called at any time to update a minimum number of
remaining frames needed, which in turn can (with the knowledge of how many
elements have been consumed by the stream) inform the next batch size.
The stack walker won’t get the next batch until all frames of the current batch
are consumed. I think the current walk methods would cover what this one does.
There are other ideas to add other variants of the walk methods and short-cut
for performance. I keep these ideas in mind and consider them once more
feedback is collected.
I think there are two problems with the current approach:
1. The function for getting the next batch size is not coupled to the
function actually doing the work. I think it is just as likely (if not
more so) that any information about the optimum number of frames to be
gathered per batch can only be sensibly determined as a result of the
current work being done. In this case, you'd have to do something odd
like use a captured shared AtomicInteger or similar to pass information
back and forth, which is not good.
2. The fact that frames are acquired in batches is an implementation
detail. I do not believe it's a reasonable expectation of a user to
know the optimum batch size; the API should not be exposing
implementation details like this. On the other hand, the user might be
reasonably expected to be able to inform the stack walker as to how many
more frames are expected to be needed. The stack walker could easily
use this information, even if it fetches in batches, by keeping a
"remainingNeeded" counter of number of remaining frames expected to be
used, which is decremented each time the stream returns an item, and
read when a new batch is needed: it could (for example) use Math.min(10,
remainingNeeded).
--
- DML
