All tests pass here now

Not sure what's wrong with ppc64 cross compilaion

#837 just confirmed that the ppc64 failure is unrelated, not sure about the macos one:(signal: 4, SIGILL: illegal instruction)

@Keruspe To figure out the crash on macOS, open.github/workflows/ci.yml and addRUST_BACKTRACE: 1 to theenv section.

Doesn't seem to give more info, but I think the ci files from master are used. I tried to temporary comment out ppc64 and the ppc64 tests were still run

I created another project to toy with the CI.

RUST_BACKTRACE=1 doesn't seem to have an impact of the macOS builder output.

The ubuntu and windows builders pass all the tests just fine. Apart from the ppc64, the other cross compilation targets pass fine too.

I'm not really familiar with debugging macos issues so I don't really know where to start

The first two commits work fine, the switch to multitask is the one causing the problem on macos

Here are the errors I'm getting on my macOS machine:https://gist.github.com/stjepang/bbe3f07c947b2fd93a47b2e667f4428a

@stjepang with this last commit, tests pass for OSX.

Looks likeasync_io::parking::Parker callsReactor::get() in itsDrop impl, which fails on OSX if no IO has been done in the current thread?

Ok, instead of using theparking crate, forcing initialization of the reactor by parking for 0ms seems to work too.

Not sure if there's a more elegant solution, something that we maybe want to fix on the async-io's side of things?

Just openedsmol-rs/async-io#4 as an alternative workaround

Thanks for the PR to async-io, this is now fixed in async-io v0.1.4.

Apart from the ppc64 cross compile which is broken even outside of this PR, everything should work fine now

Looks good to me :) If all goes well, I think it’s time to stabilize crates async-io, blocking, and multitask.

Rebased on top of master

I think you can now removefutures-timer from the[dependencies] section inCargo.toml

It's still used if unstable is enabled and default disabled it seems?

yes it is needed atm when there is no runtime at all imcluded

Right, so we should be able to remove the dependency in the typical case. It pulls in a lot of transitive dependencies...

@stjepang maybe the timers could live in their own crate? that way we could use them in the non runtime build, without pulling in anything else.

@dignifiedquire Timers live in theasync-io crate. We should exclude that dependency in the non runtime build.

I don't think there's a way to specify in Cargo.toml that a dep should be there only if an option is unset (wrt futures-timer).

It doesn't seem to bring that much deps when wasm-bindgen isn't enabled though?

Is the nightly fixed now?

Should be

With the switch to async-executor, the code is simpler, we gain more integration with smol 0.3, but the caveat is that tasks spawned onto the multi-threaded global executor cannot run local tasks anymore (since async-executor can only run the multi-threaded executor or the local executor on a thread but not both, so the runtime threads now only runs the global multi-threaded one)

With something likesmol-rs/async-executor#3 + reverting thesrc/rt/mod.rs change and droppingtask::executor::run_global works too and restore the previous behaviour WRT local tasks

What if we restrictspawn_local() as suggested here?#815 (comment)

That would simplify things because onlyblock_on() would run aLocalExecutor, and spawned threads would only run anExecutor.

Then I guess that's more or less what the current port to async-executor does?

@stjepang What about returning anOption<Task<T>> fromTask::local() instead of panicking? This leaves the choice to the caller to panic or handle the lack of local executor more "softly"

I expect in 99% cases people will just doTask::local(future).unwrap(), having the same effect. That said, it would be good to have a way of checking "am I inside an executor?", but I don't think it should block this PR...

Anything else holding this PR back?

Anything else holding this PR back?

• seems CI is sad for some reason
• the code looks good, but I want to give it a test run on a largish codebase I work on to make sure I don't see any surprises

CI is just windows probably never tested without default and with unstable.

Squashed those fixes into one commit and rebased

Something to be aware of in case you see issues related to Timers:smol-rs/async-io#6

smol now being divided in smaller crates

way smol being divided in smaller crates???

Is there discussion on why smol / async-std was preferred to tokio for tremor? I'm trying to understand tremor as well as building some Rust async support for a cloud-native project. The info would be helpful. Thanks.