On Sat, Feb 16, 2019 at 4:19 PM Andi Mullaraj <andimulla...@gmail.com> wrote: > 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. > > They create their own selector. I have hard time imagining one selector > implementation being able to support various protocols at once.
That is the case today. I can use one selector event loop today to support TCP (including SSL) as well as UDP, even SCTP. The point of selectors is to combine many things into one event loop. > 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. > > 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. It is definitely not OS-dependent; something in the end has to call selector.select(), and that thing is indeed a thread. I understand the urge to make SSL with Selectors easier, because right now it is very painful. But this approach is unlikely to succeed, at least in the JDK. -- - DML
