I realize this is a bit far off, but I think this ...

# io

[kevin.cianfarini]

I realize this is a bit far off, but I think this would be of value for people to see. Async/IO for native might be trivialized some if we bind to libevent https://github.com/libevent/libevent

[kevin.cianfarini]

From what I've read, it's all callback based. This is their recommended documentation http://www.wangafu.net/~nickm/libevent-book/

[e5l]

Btw. I checked http://software.schmorp.de/pkg/libev.html as alternative. Its really small and nice covers with cinterop.

[kevin.cianfarini]

Oh nice!

[kevin.cianfarini]

That is nice

[kevin.cianfarini]

I'm going to check it out and play around with it

[kevin.cianfarini]

thanks for sharing

[kevin.cianfarini]

inotify support

😎

[kevin.cianfarini]

Food for thought, Python implemented their own abstraction layer on kernel async offerings. https://github.com/python/cpython/tree/master/Lib/asyncio

[kevin.cianfarini]

And another option https://github.com/libuv/libuv

[kevin.cianfarini]

I also found this talk informative

https://youtu.be/nGn60vDSxQ4▾

[jimn]

wow, handwaving because NIH[.js]

[kevin.cianfarini]

@jimn nih.js?

[jimn]

calling select a bingo algorithm is a far reach, and declaring select(8) to be Bingo! algorithm in the name of node.js just deserves the "I apoligize" explanation from the main creator of node.js. I will assume he also meant libuv in his apoligy. this looks like nothing other than NIH - "not invented here"

[kevin.cianfarini]

I think that's a pretty short sighted view to have on it. Libevent also recognizes that select is the least scalable way to achieve asyncio.

Just because someone tried to make a simplified explanation of an api to a broad audience doesn't mean you should disqualify the library as a candidate for kotlin.

[jimn]

with regards to performance, context switch measurements, etc. of async IO, abbreviating explanations is short sighted. having reference benchmarks would help. even a spark line would help

[jimn]

in select vs epoll there is a limit of fd's to 1024 in a select wait set, where epoll, specific to linux, has per-event nodes pushed to events. kotlin has coroutines which is present in neither of c nor v8, which would support the more portable select() behavior using pooled coroutines without a context switch required by concurrent blocking threads. one might surmise that using python or JS without coroutines would in fact look like Bingo! on a 1024 descriptor limit and a single threaded blocking call to pselect.

Given the architecture goals of kotlin, I would be inclined to go with NIH 😉 and bake IO the hard way from libc exports

[kevin.cianfarini]

asyncio in python uses the coroutine model. Whether or not they're pooling those coroutines, I don't know.

However, the standard asyncio module distrbuted with CPython is at least 2x slower than an asyncio framework replacement built on top of libuv. That's just one example of a high profile project that isn't as successful with the NIH philosophy.

http://magic.io/blog/uvloop-blazing-fast-python-networking/

[jimn]

your link highlights that golang async IO is an unbeaten benchmark. I think I would be focussing on C++ async IO thruputs and trying to get an understanding of what limitations if any kotlin target emitters face in this area.