No

mutex

that I can see. Haven't used that before

does the JS lib have channels?

Nope. Not yet

well, doesn't look like the js core has much in it yet

js is single threaded right? in that case you could probably launch your operation in a job and use that job's existance as access control

You mean have a parent job, and run all children jobs doing get-update-set in its

coroutineContext

, that could maybe do it...

i mean something like this:

while(true) {
    if( currentJob == null )
        break
    currentJob.join()
}
currentJob = launch { ... }

and

currentJob.join(); currentJob = null

at the end, or at the end of the launch

only works if it's single threaded though...

That's a conflated behavior, not bad!

i did

private var runningJob: Job? = null
  private val queuedJobs = mutableListOf<Job>()

and then each job checks the queue at the end and promotes + calls start()

hacky single-threaded locking

i guess those should be

suspend fun

Hi guys, greetings from Munich. Let’s say I have 10 threads that a polling different tables from the same system. What is the preferred way to implement this with kotlin so that the 10 threads have a different logic but every thread uses the same connection ?

So I don’t want to open 10 connections

You could look at https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#fan-in, and use an actor https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#actors for the connection @dominik.sittel

How to make an

async

block launched within

launch

execute in another coroutine Context (e.g.

CommonPool

), while being a child of the coroutine launched with

launch

? My goal is to cancel the

async

block if the

launch

block is cancelled.

@louiscad maybe you should use the same coroutine context in

async

as in

launch

@antifaton My goal was to have

async

as a child of

launch

, while having them execute in different dispatchers. I tried using

async(coroutineContext + CommonPool) { ... }

and it seems to work (my code is a bit complex to be sure at the moment)

@louiscad ^ That is exactly how you are supposed to do it

An alternative approach that does almost the same thing is

async(CommonPool, parent = coroutineContext[Job])

The difference is that the later also inherits other context elements and the former does not. If you don’t use any custom coroutine context elements then it does not matter for you.

@elizarov What are these other coroutine context elements? I know only the Job and the dispatcher at the moment

@louiscad Out-of-the box we have only

Job

,

CoroutineDispatcher

, and an optional

CoroutineName

and

CoroutineId

to be used for debugging. Everything else == custom stuff that you might have to keep your app-specific “coroutine-local” variables.

@elizarov Searching through, I found

CoroutineExceptionHandler

that could be part of a coroutine Context. How can I use this?

I'd like to use it to make an extension on

Job

that would allow me to catch exceptions that may happen in the

launch

block

Also, is there a way to retrieve the current coroutineContext from a suspend function that doesn't have

CoroutineScope

as its receiver?

Finally: Is there any examples of what to put and what to not put inside a coroutine context? I'm a bit confused about how it can be used in the real world

@louiscad Good catch.

CoroutineExceptionHandler

also