I'm working on a project with an API running in the JVM and a JS client to access this API from the browser. The data classes of those objects which are converted to/from JSON are in a multiplatform module so that I can reuse the code on both platforms and don't accidentally end up with mismatched attributes. At this point it would be nice to also have the APIs interface in this mutliplatform module which then would be implemented and hosted in the JVM and implemented and presented in the browser. However, all methods of this interface need to be suspending in the browser since requests are (at least with Ktor's client, which I'm using) while they do not need to be suspending in the JVM.
Is there a good reason against having all those methods suspending even though I don't make use of it in the JVM? I know that methods usually should be suspending only if it's actually needed, but then I would be writing all the same interfaces (besides the suspend keyword) twice which seems like a lot of unnecessary boilerplate code to me. The methods which would unnecessarily be marked as suspending are called from suspending contexts (I'm using Ktor in the JVM too) so restricted usage wouldn't be a problem.
This seems like a matter of preference, really. Both using suspend and not using it have disadvantges, so you have to choose which weigh less.
From what you write, it seems that the advantages of using suspend (write code only once) outweigh the disavantage of polluting the interface with an unnecessary modifier. I am not aware of the possible runtime overheads here. Personally, I would opt to go with suspend.
The methods which would unnecessarily be marked as suspending are called from suspending contexts (I'm using Ktor in the JVM too) so restricted usage wouldn't be a problem.
This is the key point: the biggest hassle of the unnecessary suspend is having to launch a coroutine. If you're already inside a coroutine, the overhead of just one function along the call path being unnecessarily suspend is very low: a single extra object allocated per call.
While it's true that with having one interface you avoid boilerplate and you get the hassle of having to launch a coroutine on JVM, I'd consider another perspective:
When designing your abstraction IMO you shouldn't get much into implementation details, instead of thinking how jvm and/or js handles communication with the api I'd go with the question "Do I want to leave room for the platforms to handle this communication in an async/suspend way?". I believe this way you'll arrive to a more scalable solution, but true you'll lose out on some of the micro-optimizations
Related
I'd read a lot of the many adventages of using coroutines, but I find nothing about why you shouldn't or couldn't use them.
Why not use all methods as suspend methods, by the way?
I'm having some trouble to understand some concepts here, so with my question I pretend to make the opposite case (why not use it), so I can understand better by contrast.
The main reason not to have all functions suspendable is the overhead they introduce, at least on the JVM. Every suspendable function compiles into a Java method that receives another parameter, the continuation object, and its body compiles into pretty complex state machine code that, among other things, always instantiates another continuation object and daisy-chains it to the one received as the parameter.
So, whenever you have nothing to gain from coroutines, you shouldn't use them as the default way to do things.
Please see my answers inline to your questions:
but I find nothing about why you shouldn't or couldn't use them.
Answer:
a. You should not use them for any foreground task.
b. You should not use them for any simple/real quick operations.
c. You should not use them for any kind of initialization.
Why not use all methods as suspend methods, by the way?
Answer:
a) This will be treated as code smell. Bad practice to do so.
b) If you mark all functions as suspend, then whenever you want to call a suspend function you will have to create a Coroutine Scope to run it.
c) Testing of suspend function is difficult. It needs some additional setup of RunBlockingTest from AndroidX.
The title states my question.
What is exactly the reason why CoroutineScope.launch and Coroutine.async are just extension functions of CoroutineScope instead oa a member function?
What benefits does it provide?
I am asking because maybe the reason behind this design could be helpful in designing things in the future too.
Thank in advance.
Mostly because with extension functions it is easier to structure your code in multiple modules even if it is represented as one class.
CoroutineScope is actually a really good example of this design pattern. Take a look at CoroutineScope.kt where the interface is declared. There is only basic functionality there (plus operator and cancel())
The two functions you mentioned are defined in Builders.common.kt. If You take a look at the contents of this file, you can see that there are multiple classes which are private, this means they can only be used in this file. This tells you right away that you don't need this these classes for the basic functionality which is designed in CoroutineScope.kt, they are only there for launch {...} and async {...}
So if you have a large class with multiple functionality, it makes sense to break it up in multiple files (=modules).
launch and async are coroutine builders, but they aren't the only ones: look in integration modules for future (and another future), publish, the RxJava 2 builders etc. Obviously those can't be members of CoroutineScope, so why should launch and async be?
In addition, by being extension functions you know they don't rely on any CoroutineScope privates (well, they could rely on internals since they are in the same module).
The kotlinx.coroutines uses structural concurrency approach to make sure all errors are propagated to a parent coroutine. Similarly, a parent coroutine will by default wait for all it's child coroutines to complete.
There is a Job object associated with every coroutine when you do launch or async. It is just easier to use extension functions for that design to make it work implicitly, without a code-writer explicit attention
You may have a look at the more detailed explanation :
https://kotlinlang.org/docs/reference/coroutines/basics.html#structured-concurrency
https://medium.com/#elizarov/structured-concurrency-722d765aa952
I am new to Kotlin, have written a class in kotlin to perform database operation
I have defined database connection in constructor using init but I want to close database connection using destructor.
Any Idea of how to achieve this using kotlin destructor?
Currently I have wrote a separate function to close connection, which i want to have it using destructor like any other programming language like php,etc
Handling resources that need to be closed in Kotlin
You can make your Database Wrapper extend Closeable. You can then use it like this.
val result = MyResource().use { resource ->
resource.doThing();
}
This way inside the use block your resource will be available, afterwards you will get back result, which is what doThing() returns, and your resource will be closed. As you haven't stored it in a variable you also avoid accidentally using the resource after it is closed.
Why to avoid finalize
Finalise is not safe, this describes some of problems with them, such as:
They are not guaranteed to run at all
When they do run there can be delays before it runs
The link sums up the problems like this:
Finalizers are unpredictable, often dangerous, and generally unnecessary. Their use can cause erratic behavior, poor performance, and portability problems. Finalizers have a few valid uses, which we’ll cover later in this item, but as a rule of thumb, you should avoid finalizers.
C++ programmers are cautioned not to think of finalizers as Java’s analog of C++ destructors. In C++, destructors are the normal way to reclaim the resources associated with an object, a necessary counterpart to constructors. In Java, the garbage collector reclaims the storage associated with an object when it becomes unreachable, requiring no special effort on the part of the programmer. C++ destructors are also used to reclaim other nonmemory resources. In Java, the try-finally block is generally used for this purpose.
If you really need to use finalize
This link shows how to override finalize, but it is a bad idea unless absolutely necessary.
CompletableDeferred documentation says
All functions on this interface and on all interfaces derived from it are thread-safe and can be safely invoked from concurrent coroutines without external synchronization.
Is it safe to call these functions outside any coroutine?
For SendChannel<E>, offer and close are not suspend and so they can be called outside coroutines syntactically, but is it actually safe to do so?
If a coroutine is needed, what is the cheapest way to start one: launch(Unconfined)?
It is safe to call offer and close from anywhere. That is what documentation means to say with "are thread-safe" phrase.
One of the reasons these methods are included into channel APIs is to enable integration of coroutines with the regular non-coroutine world that is based on various callbacks and event handlers. You can see the actual example of such integration in this guide on UI programming with coroutines.
From the official guide and samples from web, I didn't see any mentions of locking or synchronization, or how safe is modifying a shared variable in multiple launch or async calls.
Coroutines bring a concurrent programming model that may result in simultaneously executed code. Just as you know it from thread-based libraries, you have to care about synchronization as noted in the docs:
Coroutines can be executed concurrently using a multi-threaded dispatcher like the Dispatchers.Default. It presents all the usual concurrency problems. The main problem being synchronization of access to shared mutable state. Some solutions to this problem in the land of coroutines are similar to the solutions in the multi-threaded world, but others are unique.
With Kotlin Coroutines you can make use of acquainted strategies like using thread-safe data structures, confining execution to a single thread or using locks (e.g. Mutex).
Besides the common patterns, Kotlin coroutines encourage us to use a "share by communication" style. Concretely, an "actor" can be shared between coroutines. They can be used by coroutines, which may send/take messages to/from it. Also have a look at Channels.