:mega: ktor `1.0.0-alpha-1` has been published Kotlin `1.3.0-rc-131` (both JVM and Native) kotlinx....

# ktor

[cy]

📣 ktor 1.0.0-alpha-1 has been published

Kotlin 1.3.0-rc-131 (both JVM and Native)
kotlinx.coroutines 0.30.2-eap13

Migrated to coroutines structured concurrency (see `https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/basics.md#structured-concurrency`). Now all ktor handlers (including websocket) have relevant coroutiune scope.

Please note that it is important to use with 1.3.0-rc-131 and not mix with incompatible coroutines versions.

[dave08]

Per request scope, or application wide?

[cy]

request scope

[cy]

or web socket session

[lukaswelte]

So when the request is cancelled it will cancel all the coroutines within the request?
Is it a supervisorScope or a coroutineScope?

[cy]

yes, exactly

[cy]

and vise-versa: crashing sub-coroutine will cancel request handling

[lukaswelte]

Nice 👌
Will an error handler be called in the case of a sub-routine cancelling the request (I’d guess so since the cancellation is also just a throwable)?

[cy]

As you said it is just a cancellation exception so it will be caught and handled

[dave08]

Is the request scope exposed somehow (like to launch from it)? Like on the ApplicationCall object or something?

[cy]

PipelineContext is a CoroutinScope so you can launch coroutines everywere in handlers and interceptors

[cy]

Application doesn't have scope (undecided yet)

[dave08]

You could have a SupervisorScope for the Application... although if the application stops, then the process also goes along with it's coroutines, unless someone is running more than one application (like me, since I have to open two ports, one for internal requests and the other for external ones...) or has some application failure recovery logic.

[cy]

Well, it's not clear what could be done.. Perhaps embeddedServer could be called on a scope for that purpose

[dave08]

But then all the requests should be its children... and what if the app runs not on the development server? Also the TestApplication might need a scope to cancel all the coroutines on its requests... that might be a more common use case since a server is created for each test.

[cy]

All requests are server's children, you just don't see server's root job

[dave08]

So they are currently all in GlobalScope, and will all be cancelled with it?

[cy]

not GlobalScope, there is server's root scope (job)

[cy]

we simply don't have public API to access it

[cy]

cancelling it makes impossible to do gracefull shutdown

[cy]

cancellation is the only reason for this root job to be public but we already have stop() for this

[dave08]

Well there's always NonCancellableContext

[dave08]

Oh

[dave08]

But then to launch application wide coroutines, one would need to use GlobalScope or have one's own supervisor scope around the routing or something...

[dave08]

And it wouldn't listen to stop()

[dave08]

So in TestApplication... they would need to be cancelled somehow

[cy]

Ok, I see

[cy]

Then perhaps we need it so you can launch them just like application.launch {}

[dave08]

I have `Actor`s that are running for all the requests to queue a certain heavy type of task to, for example, and the request returns right away...

Right.

[gildor]

Yeah, I have the same case as Dave about an actor, so application level scope would be really useful.
Not a big difference in my case with GlobalScope, but looks more explicit and can be useful if you have multiple applications