RFR: 8151299 Http client SelectorManager overwriting read and write events

[Claes Redestad]

On 2016-03-08 14:42, Michael McMahon wrote:
>
>> Iterator-based removal would work, or building a new list to replace 
>> pending with might be more efficient. The synchronization scheme 
>> seems a bit flaky as well?
>>
>
> The new code is always called from the same thread. So, I don't see an 
> issue?

Right, but it seems the SelectorAttachment can escape and be observed by 
other threads that may have access to the SelectableChannel. I don't 
know if this could become a problem somewhere, but it makes me a bit 
uneasy. Maybe the attachment should be an immutable key to a map of some 
tracking object held by and managed by the SelectorManager?

Also, with the assumption that the SelectorManager is running in a 
distinct thread, couldn't this be checked at the start of run() and then 
avoid synchronized(this) in the loop?

Another oddity in the surrounding code is that 
System.currentTimeMillis() is always called, but only used when 
selector.select(timeval) == 0 - could this be moved into the if-block?

  266                     long now = System.currentTimeMillis();
  267                     int n = selector.select(timeval);
  268                     if (n == 0) {
  269                         signalTimeouts(now);
  270                         continue;
  271                     }


Thanks.

/Claes