search

tdlib / td

Cross-platform library for building Telegram clients
https://core.telegram.org/tdlib
Boost Software License 1.0
7.19k stars 1.46k forks source link

ClientActor JNI #756

Closed whyoleg closed 5 years ago

whyoleg commented 5 years ago

Is it possible to somehow create low level JNI for ClientActor?

levlam commented 5 years ago

No, unless it will have an interface similar to Client. Why do you want it?

whyoleg commented 5 years ago

I'm working on library for Kotlin and in future, want to use kotlin MPP with native(c/c++/obj-c/swift) and js(webasm) implementations. In Client implementation there is a restriction, that receive method can be called only from one thread simultaneously. As I understand, this restriction is for full tdlib instance, or may be I'm wrong and it per client restriction? So in my assumption, I need to add an additional synchronization (on top of that which already exists in Client) to handle multiple users/clients (if it will be used as a server with 100, 1000, etc users). Also I've read in one of issues here, that ClientActor is faster than Client, and bot api based on ClientActor. So I want to archive maximum performance if possible.

levlam commented 5 years ago

It is a per-client restriction. You may treat different Clients as completely independent.

The only downside of Client interface is that you need a per-client thread to call Client.receive. It's not a big problem if you need up to 100-1000 Clients simultaneously.

whyoleg commented 5 years ago

Big thx for clarification this part! But, anyway, it will be also good to somehow use ClientActor, will it be possible in future? Or even somehow now with additional C++ glue code?

levlam commented 5 years ago

It is not possible to directly wrap ClientActor using JNI.

To trade some usage simplicity for some performance, the Client class needs to be replaced with some other class, which will also use ClientActor internally and can be used from other languages.

But this is very unlikely to be needed. because performance of Client class should be enough for almost any application. Threads waiting for updates in Client.receive should consume almost zero system resources, and this is the only thing that could be optimized more in the Client interface.

whyoleg commented 5 years ago

Thx, will keep in mind!