i am looking at <https://github.com/jnorthrup/ktor...

# ktor

[jimn]

i am looking at https://github.com/jnorthrup/ktor/blob/10a73efff92e01023d94fc0167064240c0cb8ec1/ktor-network/src/io/ktor/network/selector/Selectable.kt#L38

[cy]

it is required to make lists of selectables with no allocations

[jimn]

im not sure i understand, you have to allocate the Node object and you still retain the same amount of NIO objects

[jimn]

i dont see a complete NIO coroutines example in ktor but im attempting to recreate the minimalist NIO selector loop for discussion purposes...

[cy]

you don't need to write your own selection loop

[cy]

open sockets instead

[cy]

aSocket().tcp().connect()...

[cy]

or aSocket().udp().....

[cy]

this API has been moved from kotlinx.sockets and not yet documented

[cy]

also look at http server: https://github.com/ktorio/ktor/blob/68522d088c59cbf64472269a7ff1239f9dfb6be0/ktor-server/ktor-server-cio/src/io/ktor/server/cio/HttpServer.kt

[cy]

(experimental CIOEngine)

[jimn]

so at this time the only documented thing to do is coroutines with NIO right?

[jimn]

it would be nice to pass along a SocketChannel to CIO for the various features but i rather enjoy the NIO api personally

[cy]

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)

[jimn]

ByteBuffer has a following these days. i think it was hinted that misc.unsafe got preferred treatement with hotspot jit

[jimn]

im not a fan of select() either but for the fact it is the only epoll feature in the jvm

[cy]

we are thinking of Kotlin Native actually

[jimn]

and it holds all the keys to accessing mmap and direct IO

[cy]

so CIO should be portable across JVM and Native

[cy]

for now we only have NIO implementation

[cy]

and it seems to perform well

[cy]

what exact features of NIO would you like to see in CIO?

[jimn]

documented and bulletproof sslengine, of any variety

[jimn]

its impossible with the jvm

[jimn]

I bled writing https://github.com/0xCopy/RelaxFactory for 5 years, it is smaller and more painful than anything ktor is borrowing right now

[jimn]

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

[cy]

for now it is difficult to compete with golang due to many reasons (including NIO limitations)

[cy]

and still there is much to do to compete with netty

[cy]

but note that ktor provides high level API that is much more fun than netty 😉

[jimn]

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.

[jimn]

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

[jimn]

c++ STL iterators and bytebuffer have some parity

[jimn]

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.

[jimn]

i would definitely prefer LLVM backend dev elopment to jvm with io intensive code

[cy]

how do you translate grammars?

[cy]

Kotlin Native is still in progress and still there is much to do, but you could try it anyway

[jimn]

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

[jimn]

based on exposure to boost::spirit

[jimn]

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

[jimn]

there's a threadlocal behind the curtains tracking the state.

[cy]

threadlocal should be avoided somehow

[jimn]

i am only just beginning to figure out coroutines and coroutine contextes and apply/also/run/with

[jimn]

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..

[jimn]

this gotcha made the threadlocal more or less guaranteed. coroutines would need to pin the thread, any hints greatly appreciated.