By NIO2, I meant the following style of flow-control (back-pressure), in pseudo code:
channel.notifywhenreadable(callback) // edge trigger ideally channel.notifywhenwritable(callback) int channel.availablebytes(); int channel.read(int, buf); // always from callback int channel.write(buf); // always from callback HTTP always assumes a byte-stream transport (even over UDP), and the above flow-control style is easy to understand and maps well to the underlying OS/transport. There could be other variants to the above style, but if "Flow" is the future, then there is no point to invent another style IMO. - Wenbo On Fri, Jul 31, 2015 at 11:52 AM, Simone Bordet <simone.bor...@gmail.com> wrote: > Hi, > > On Fri, Jul 31, 2015 at 8:37 PM, Wenbo Zhu <wen...@google.com> wrote: > >> > Or we follow the NIO2 model (readiness), > >> > >> Please no ! :) > > > > Ignoring the epoll part, is the issue in the API styles or the actual > model? > > https://webtide.com/on-jdk-7-asynchronous-io/ > > and > > http://www.slideshare.net/SimoneBordet/servlet-31-async-io, from slide > 22 onwards. > > NIO2 is not an API I would like to see replicated/used in HttpClient. > > I know of people that are already upset with the current API because > it forces too much allocation. > That's because of the API, not because of the implementation. > > Now, perhaps these people are at one extreme of the spectrum, but > certainly it is something we want to care about for an official JDK > API. > For example, the current API forces the allocation of a URI object for > every request. That may be saved by changing the API (or supporting an > overloaded version that takes a String). > > Me, I'd like to get the semantic right first, and then look at > opportunities for improving performance. > > -- > Simone Bordet > http://bordet.blogspot.com > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz >
