Hi, On Thu, Apr 7, 2016 at 3:27 PM, Michael McMahon <michael.x.mcma...@oracle.com> wrote: > At the lowest level the implementation uses two threads per TCP connection, > one for reading and one for writing.
Ugh. > I do plan to change that to dispatch from > the selector > and execute the reads and writes asynchronously. It's not a particularly big > change, > but would prefer to do it after the first integration of this code. Well, in my experience this kind of change has huge implications. Perhaps you are right that in your case is not big, but I would not take it lightly, not even for a moment. > The Stream layer above this behaves much the same as in Http/1.1. where it > uses a single thread invocation for sending each request body and receiving > each > response body. So, it's not exactly blocking. Nor is it entirely > asynchronous/non blocking. And it's really confusing to review :/ Maybe you can clarify why it has been implemented in this hybrid way, to then rewrite it asynchronously ? It will help reviewers (at least me) to understand the implementation choices (which now appear as "wtf" moments). Thanks ! -- 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
