Asynk-nio library

Libraries
1

Hi all,
I am planning to develop some Kotlin extension methods for some common, officially unsupported, asynchronous libraries.
I will release this work under the MIT license.

I started this work on Java NIO, I wrote an initial implementation here with a really low memory pressure (continuation listener is a singleton).

Every contribution will be appreciated.

The library is available here: Asynk / nio · GitLab
A README file was already planned and I hope to release it soon on jcenter.

Thank you.

4 Likes
2

There is some discussion going around the design of suspended version of kotlinx-io. We should discuss it more in #io channel in slack.

1 Like
3

Hi, @darksnake,
thank you for a quick response.

IMHO I consider a chat not so great for issue tracking.

Regardless this, I wish to understand why kotlinx-io should be related with the mentioned library, kotlinx-io is a multiplatform, in development full-featured library, instead asynk-nio is a tiny adapter over Java NIO, I think that any naming concerns are related to NIO interfaces only.
What do you think about it? Can you explain your issue, please?

4

Kotlinx-io is multiplatform, but it will have JVM implementation. We need to understand what functionality do we need from suspended IO and how to better generalize it.Your library does not seem to do actual read from buffer, but probably it is the next step, so I suggest a discussion.

5

Thank you, I will follow this issue on GitHub.

No, it isn’t. The code is done.
Each NIO asynchronous method was been mapper to a suspending extension method, so nothing was left uncovered.
How NIO Channel works with NIO Buffer was already specified in NIO documentation, it is not a part of asynk project.

6

The completion handler listener is a singleton, but two closures are allocated for each call. It would be worth some effort to avoid that for these low-level operations.

In virtually every case, when async channels are used, they are wrapped in a higher-level object that binds it permanently to dedicated handler objects, avoiding this overhead.

7

Good catch @mtimmerm,
thank you for your suggestion.

I marked inline all functions, so no extra allocation for lambda or continuation was required.

In this case, the “dedicated handler object” is the caller continuation state machine, so it can be reused.

8

The crossinline forces object allocations for the lambdas. You’ll save state machine allocations, through.

9

Are you confusing with noinline?

10

Ah, no, but I might be mistaken. crossinline disables non-local returns so the lambda can be incorporated into another one that is allocated. You pass this all the way to suspendCoroutine, though, and I guess it’s not guaranteed that suspendCoroutine will do this.

11

I checked the bytecode twice :wink: