If I create a `Job` with a parent parent is long running is

Question

If I create a `Job` with a parent parent is long running is it a memory resource leak to not complete or cancel the Job Will the parent hold on to it and prevent it from being garbage collected

octylFractal · Answer

yes

octylFractal · Answer

since the parent is required to cancel all child jobs when it itself is cancelled

diesieben07 · Answer

Hm That sucks smile How do I best deal with this situation The parent job is a `SupervisorJob` for a service implementation When the service gets a request I start a child job for that request This handle is handed out to third party code how do I ensure that I clean up my job if the third party code fails throws an exception

streetsofboston · Answer

Do you return the `Job` of each request to the caller If so why

diesieben07 · Answer

``` third party code interface Callback fun onMessage message Any fun onComplete my code class MyService ThirdPartyInterface val job = SupervisorJob override fun someOperation responseListener Callback Callback val requestJob = Job job return object Callback handle onMessage etc here write responses to responseListener this spawns processing coroutines using requestJob as such I must ensure to properly dispose of it ```

octylFractal · Answer

typically you should adapt the callback to a suspend function see <https medium com elizarov callbacks and kotlin flows 2b53aa2525cf>

streetsofboston · Answer

To avoid tracking your Jobs in your own code use CoroutineScopes instead

octylFractal · Answer

tbh I think that for this style of interface you should be launching an independent job for each callback with no parent

diesieben07 · Answer

I want a parent job for all requests though how do I do that with CoroutineScope

diesieben07 · Answer

How do I then close this service

diesieben07 · Answer

If I dont have a parent

octylFractal · Answer

well `CoroutineScope` always contains a Job

diesieben07 · Answer

I know that

octylFractal · Answer

you can pass `SupervisorJob` to have a parent

octylFractal · Answer

doesn t really change anything about the cancellation though

octylFractal · Answer

I think I don t know enough to say what the appropriate step is here

streetsofboston · Answer

diesieben07 · Answer

Even if I use `CoroutineScope` it doesn t solve my problem because now I need to properly dispose of that

streetsofboston · Answer

CoroutineScopes do solve your issues They keep track of Jobs and cancel dispose of them properly

diesieben07 · Answer

I know about coroutine scope and I know how it works But it doesn t solve the problem of having to hand out stuff to other code which is written in Java and not aware of coroutines

streetsofboston · Answer

Let me take a quick peek at your code snippet and see how you could use CoroutineScopes to manage Jobs

streetsofboston · Answer

You should not return Jobs return Futures instead CompletableFutures

streetsofboston · Answer

diesieben07 · Answer

I can t return a future `ThirdPartyInterface` is a callback based API

diesieben07 · Answer

`someOperation` is an implemenation of a third party interface

octylFractal · Answer

is it possible for us to see the full interface

Casey Brooks · Answer

The reason you d typically want to hold onto a `Job` is so that you can cancel it in response to application lifecycles Otherwise coroutines will tidy themselves up To handle other code you should find some way to bind it to the world of coroutines You can wrap a callback based API into a coroutine with `suspendCancellableCoroutine` ```suspendCancellableCoroutine lt String gt cont gt someJavaMethodWithACallback cont resume it ``` <https kotlin github io kotlinx coroutines kotlinx coroutines core kotlinx coroutines suspend cancellable coroutine html>

diesieben07 · Answer

< octylFractal>

diesieben07 · Answer

And before you say you should use a coroutine aware grpc generator that is what I am working on

diesieben07 · Answer

< Casey Brooks> `suspendCancellableCoroutine` requires me to be in a suspending function already And it is also just a one off There can be many messages going in and out of the callbacks

octylFractal · Answer

it looks like Listener allows you to bind `onCancel` `onComplete`

octylFractal · Answer

I would just bind those to closing the job and not worry about it if those never get called

diesieben07 · Answer

That s quite optimistic in a network scenario smile

octylFractal · Answer

if those don t get called I would consider that a bug in grpc

octylFractal · Answer

considering Cancellations can be caused by timeouts explicit cancellation by the client network errors etc

octylFractal · Answer

even in a network scenario grpc claims `onCancel` will be called

Casey Brooks · Answer

`Flow` might be closer to what you re wanting than a raw coroutine

streetsofboston · Answer

```class MyService ThirdPartyInterface val job = SupervisorJob override fun someOperation responseListener Callback Disposable val scope = CoroutineScope job return object Disposable override fun dispose scope cancel scope launch handle onMessage etc here write responses to responseListener this spawns processing coroutines using requestJob as such I must ensure to properly dispose of it ```

diesieben07 · Answer

Again you are changing what I am returning which I can t do

diesieben07 · Answer

thank you Octavia it seems I was a bit to pessimistic maybe I ll follow your advice

streetsofboston · Answer

You need something to be cancelled by the caller

streetsofboston · Answer

It the caller can t cancel it you can still return the Callback and have it properly cleaned up on exceptions or finishing of the requests

streetsofboston · Answer

```class MyService ThirdPartyInterface val scope = CoroutineScope SupervisorJob override fun someOperation responseListener Callback Callback scope launch handle onMessage etc here write responses to responseListener this spawns processing coroutines using scope as such I must ensure to properly dispose of it return responseListener ```

diesieben07 · Answer

Thanks everyone for your replies

streetsofboston · Answer

In my last example code above when code inside the `launch` throws an exception or just finishes any Jobs associated with it will be cancelled clean up and garbage collected The CoroutineScope will take care of that You may want to install a CoroutineExceptionHandler in the constructor of he `CoroutineScope` as well to handle any unhandled un caught exceptions

diesieben07 · Answer

Yes I know about CoroutineScope

streetsofboston · Answer

But won t it solve your problem of possibly leaking Jobs

diesieben07 · Answer

My problem was that I thought I didn t have a I am done callback on my third party interface when in fact I do

streetsofboston · Answer

Ah I see slightly smiling face