i am looking at <https://github.com/jnorthrup/ktor...
# ktor
c
it is required to make lists of selectables with no allocations
j
im not sure i understand, you have to allocate the Node object and you still retain the same amount of NIO objects
i dont see a complete NIO coroutines example in ktor but im attempting to recreate the minimalist NIO selector loop for discussion purposes...
c
you don't need to write your own selection loop
open sockets instead
aSocket().tcp().connect()...
or aSocket().udp().....
this API has been moved from kotlinx.sockets and not yet documented
(experimental CIOEngine)
j
so at this time the only documented thing to do is coroutines with NIO right?
it would be nice to pass along a SocketChannel to CIO for the various features but i rather enjoy the NIO api personally
c
I believe we would like to hide NIO behind to go multiplatform (so one day we will be able to rewrite it on top of POSIX/epoll/kqueue and keep the same API)
j
ByteBuffer has a following these days. i think it was hinted that misc.unsafe got preferred treatement with hotspot jit
im not a fan of select() either but for the fact it is the only epoll feature in the jvm
c
we are thinking of Kotlin Native actually
j
and it holds all the keys to accessing mmap and direct IO
c
so CIO should be portable across JVM and Native
for now we only have NIO implementation
and it seems to perform well
what exact features of NIO would you like to see in CIO?
j
documented and bulletproof sslengine, of any variety
its impossible with the jvm
I bled writing https://github.com/0xCopy/RelaxFactory for 5 years, it is smaller and more painful than anything ktor is borrowing right now
I have elixir and golang on my todo list but kotlin is more fun. they are both noted for solving the same problems with low debt
c
for now it is difficult to compete with golang due to many reasons (including NIO limitations)
and still there is much to do to compete with netty
but note that ktor provides high level API that is much more fun than netty ­čśë
j
I stopped when the benchmarks i was producing were on par with netty. i started working on composing macro operations in bytebuffer and have my own continuation style in java.
I am happy having a BNF-sh grammar translate directly to the IO parsers with 100% directbytebuffers and still keep up with jetty and netty
c++ STL iterators and bytebuffer have some parity
i'd like to be able to port golang code into a similar set of kotlin metaphors just CBF to do it myself. not this week.
i would definitely prefer LLVM backend dev elopment to jvm with io intensive code
c
how do you translate grammars?
Kotlin Native is still in progress and still there is much to do, but you could try it anyway
j
i havent figured out the threadlocal replacement for pure kotlin yet... but https://github.com/jnorthrup/unaryparser/blob/master/src/main/java/sun/misc/unreal/nars/nars.java was a grammar that drove a lot of work back into lower level bytebuffer parser libs
based on exposure to boost::spirit
intensionaldifference(confix(strlit("(~"), chlit(')'), skipper(term(), chlit(','),term()))), is i think an enum constant that drives a set of bytebuffer unary functors along tristate branch conditions
there's a threadlocal behind the curtains tracking the state.
c
threadlocal should be avoided somehow
j
i am only just beginning to figure out coroutines and coroutine contextes and apply/also/run/with
it looks like the hierarchical corutine context can handle the role of threadlocals, particularly if there is a declarative default to make the "grammar" declarations terse without explicit context params. but NIO has a gotcha that selection events must occur within the same thread as registration. and iiuc, the brioef mention it had in javadocs has been erased but it still seems to apply..
this gotcha made the threadlocal more or less guaranteed. coroutines would need to pin the thread, any hints greatly appreciated.