<div dir="ltr"><div dir="ltr">Thanks David,<div><br></div><div>> That is the case today.  I can use one selector event loop today to</div><div>> support TCP (including SSL) as well as UDP, even SCTP.  The point of<br>> selectors is to combine many things into one event loop.<br></div><div><br></div><div><div>Is this (to use one Selector class only for all protocols) a requirement in JDK? I haven't seen it, but even if it were (such requirement):</div><div>1. I mentioned that the SSLSelector that I am proposing would be able to select on whatever the default Selector is able to, plus the SSL socket channels. </div><div>2. It would also be able to perform everything without the need for any extra threads.<br></div></div><div>3. It would not be anymore an obstacle to additions (such as SCTP) than the current one (plain sockets) is (if it were to make it to JDK, obviously)</div><div><br></div><div></div></div><div>> It is definitely not OS-dependent; something in the end has to call<br>> selector.select(), and that thing is indeed a thread.<br></div><div><br></div><div>I am beginning to think we might be on different pages here. Someone from outside the selector calls selector.select(), and all selector's functionality is handled within the context of the calling thread. So where is the need for the extra thread here? More specifically, in the SSLSelector case, a call to its select, ends up usually to a call to its inner selector.select(), always in the context of the calling thread ... so same thing again. Why do you think another thread is necessary here (within the selector itself)?<br></div><div><br></div>> I understand the urge to make SSL with Selectors easier, because right<br>> now it is very painful. <div><br></div><div>Total agreement. I have one full year of development notes to show how painful it is. I am talking about a fully functional, completely compatible Selector, (down to the lock obtention order -- sometimes 6 to 8 locks to be always kept in order) to vouch for that.</div><div><br></div><div>> But this approach is unlikely to succeed, at least in the JDK.<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br></div><div class="gmail_attr">Would you mind clarifying which part doesn't fit the bill? Let's understand well what is proposed first: A JDK enhancement of Selector/SocketChannel/ServerSocketChannel able to provide the same exact functionality across all existing channels (UDP/TCP) as well as SSL. It can be implemented in pure Java, with no extra threads for selection, with minimal cpu and memory impact (only for SSL channels) over the current implementation.</div><div class="gmail_attr"><br></div><div class="gmail_attr">If I were the JDK steward, I wouldn't know what to ask for more. Am not, and thats the reason I am putting all this under SSLSelector/SSLSocketChannel implementation, instances of which provide the same proposed functionality.</div><div class="gmail_attr"><br></div><div class="gmail_attr">Thanks,</div><div class="gmail_attr">--Andi</div><div class="gmail_attr"><br></div><div class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Mon, Feb 18, 2019 at 5:47 AM David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Feb 16, 2019 at 4:19 PM Andi Mullaraj <<a href="mailto:andimullaraj@gmail.com" target="_blank">andimullaraj@gmail.com</a>> wrote:<br>
> 2. What if someone decides to take the exact same approach to solve some other higher-OSI-layer protocol decoding? Now you have to choose which kind of protocol you want your selector to support.<br>
><br>
> They create their own selector. I have hard time imagining one selector implementation being able to support various protocols at once.<br>
<br>
That is the case today.  I can use one selector event loop today to<br>
support TCP (including SSL) as well as UDP, even SCTP.  The point of<br>
selectors is to combine many things into one event loop.<br>
<br>
> 3. Note that with a plain selector and plain sockets, you *need* a thread to support the event loop anyway, I mean it has to run somewhere.<br>
><br>
> I don't have enough knowledge here, but I am thinking it will depend on the OS ... if the OS provides similar hooks, then I'd say no other threads are needed -- the thread selecting would be entering a wait() until some notifier wakes it up ... not vital to the SSL part though.<br>
<br>
It is definitely not OS-dependent; something in the end has to call<br>
selector.select(), and that thing is indeed a thread.<br>
<br>
I understand the urge to make SSL with Selectors easier, because right<br>
now it is very painful.  But this approach is unlikely to succeed, at<br>
least in the JDK.<br>
<br>
<br>
<br>
--<br>
- DML<br>
</blockquote></div>
</div></div>