Krzysztof Ciesielski

@kamilkloch I re-ran your tests on Tapir 1.9.9 + Blaze, which includes your WebSocket fixes for http4s. The CPU cycles for Tapir were at 16.06%. After bumping to 1.10.0 (with...

@szymon-rd I switched scala-native to 0.5.1 and applied a few more updates, could you verify if this PR fixes the ARM issue now?

Sure, I'm on it. Thanks a lot for this investigation @WojciechMazur!

@visox I'd like to look into this, if it's still relevant. Does the problem still occur?

Together with @wydra98 we have created a nice working example: ```scala //> using toolkit latest import sttp.client4.* import sttp.client4.curl.* import sttp.client4.Response object sttpNative extends App: val backend = CurlBackend() val...

I guess we better wait for the scala-cli fix before we proceed with announcing how cool it is to write sttp apps on Scala Native? :)

Closing in favor of https://github.com/softwaremill/sttp/pull/2082

Thanks, I wasn't aware of this possibility. It sounds like something that we might want to configure on the endpoint level instead of having a global `forkExecution` setting. This would...

@oker1 Thanks a lot for this contribution! I'm OK with merging this as soon as I make sure that the flaky tests aren't related.

Bumping this, as it would really help to implement WebSocket support for `tapir-netty-zio`, where we use netty-reactive-streams underneath and need a `Processor[Req, Resp]` created out of a `ZPipeline`. Any chance...