Expose the event loop group fn separately

[lvh]

Aleph has some cool functionality for automatically picking the right event loop. Two suggestions:

• The decision to use nio or epoll could be done inside the delay
• Many applications would prefer a right-sized thread pool with daemon threads, so need to duplicate code currently in the middle of create-client

In conclusion, I'm suggesting:

• the nio/epoll choice be made inside the delay
• https://github.com/ztellman/aleph/blob/master/src/aleph/netty.clj#L665-L667 be exposed as a fn
• https://github.com/ztellman/aleph/blob/master/src/aleph/netty.clj#L648-L650 be exposed as (possibly the same) fn

If you have any opinions on how this ought to be done, I am volunteering to write the code for this.

[ztellman]

Is this for the purposes of code simplification, or reuse of this logic elsewhere?

[lvh]

Both, I guess; but mostly about reuse. E.g. I'm using Netty's DNS resolution with a little Clojure rubbed on it, and I want that functionality as well :)

I also realized why epoll and native are separate right now -- you want to be able to control which one gets used on each new client/server, not once-per-process. Right?

[ztellman]

That was the idea, though I'm not sure if that's actually useful in practice. For what it's worth, I do have a yet-to-be-finished aleph.dns namespace, which may address a few of your concerns, but I'll give it some thought.

[lvh]

Nifty. Is that available somewhere or hiding on your laptop? (I'm guessing you have more than I; all I have really is a fn that wraps .resolve, which is all I needed.)

[arnaudgeiser]

Since we introduced kqueue and io-uring, we now have two external undocumented functions.

• transport-channel : https://github.com/clj-commons/aleph/blob/master/src/aleph/netty.clj#L1312
• transport-client-group : https://github.com/clj-commons/aleph/blob/master/src/aleph/netty.clj#L1328

While those should be considered implementation details in Aleph as the internals are not encapsulated inside a dedicated namespace (e.g: aleph.http.impl), those will probably stay for a long time or will eventually have a replacement.