# Different spawning behavior of @spawn and Channel(..., spawn=true)

**URL:** <https://discourse.julialang.org/t/different-spawning-behavior-of-spawn-and-channel-spawn-true/48413>\
**Category:** General Usage\
**Tags:** multithreading\
**Created:** [October 15, 2020, 7:44am UTC](https://discourse.julialang.org/t/different-spawning-behavior-of-spawn-and-channel-spawn-true/48413 "2020-10-15T07:44:45Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![tisztamo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tisztamo/32/16200_2.png) [@tisztamo](https://discourse.julialang.org/u/tisztamo)\
**Post date:** [October 15, 2020, 9:26am UTC](https://discourse.julialang.org/t/different-spawning-behavior-of-spawn-and-channel-spawn-true/48413/2 "2020-10-15T09:26:23Z")

</div>

I have experienced similar issues when I have started threads with `@spawn` that started their life with waiting for something.

I guess your issue may be related: the scheduler thinks that the threads are available and reuses them instead of round-robin-ing. For me it seemed that this is not a bug, although it was very annoying. I ended up using your solution from here:

> [@Lightweight tasks, Julia vs Elixir/OTP](https://discourse.julialang.org/t/lightweight-tasks-julia-vs-elixir-otp/35082/22):
>
> Now in concluding this journey, I provide the following function for executing functions on specified threads: function onthread(f::F, id::Int) where {F\<:Function} t = Task(nothing) @assert id in 1:nthreads() "thread $id not available!" @threads for i in 1:nthreads() if i == id t = @async f() end end fetch(t) end Anyone having single threaded applications involving tasks can speed things up with it. With the above (contrived) example you can do j…

---

_[View the full topic](https://discourse.julialang.org/t/different-spawning-behavior-of-spawn-and-channel-spawn-true/48413)._