tokio
tokio copied to clipboard
tokio-rs
Esp idf support
This PR adds support for the espidf target for tokio.
The changes are mainly done in mio, tokio just requires a few cfg's and support for a new mio API. A merge of this PR would mean tokio with features = ["full"] is capable of running on the espidf platform.
Currently this is blocked by missing changes in mio, but with patches this works alright already. As such this PR currently includes references to forked repositories and is not suitable for merging. Opening this anyway for tracking and easier diffing.
It seems like this disables the process feature. Does it not work on that platform?
It seems like this disables the process feature. Does it not work on that platform?
Yeah, the platform does not know what a process is (neither does it have signals) as it is a single process microcontroller. As such, I have disabled these features as there are no equivalents
I don't want to litter the code-base with target_os = "espidf" conditions everywhere process or signal is mentioned. I would rather add the following to our lib.rs file.
#[cfg(target_os = "espidf")]
#[cfg(any(
feature = "process",
feature = "signal"
))]
compile_error!("Target epsidf does not support the process or signal features");
This will make it fail to compile with features = ["full"], but that's just how it is. The situation is the same for wasm.
Alright, got rid of them - 2 are remaining, but I don't think they can be removed
Ok, I just noticed something - this PR also contains changes in the unix signal driver (well, a small one), which is now not really part of this PR anymore.
The reason this change has been added is that it fixes a core being stuck at 100% when using the patched mio with the poll backend. Now, the signal driver is not used on the espidf, but it still may be in used on OS where mio in the future uses poll (provided the changes get accepted at mio).
Should I move these changes to another PR for merging when the first set of patches land in mio?
It's unclear why you are making these changes to the IO driver. Is it specific to the espidf platform, or is there a bug in the IO driver? If you don't feel that they should be part of this PR, then I would start by opening a bug report that explains the issue that these changes exist to fix.
The changes in the I/O driver are something which is required due to the patched mio version. These are required due to the waker needing a reset once it has woken to not wake again. The signal driver issue is similar but unrelated to this PR.
Such a breaking change to mio would require a major version bump and a very good justification. (But that discussion should not happen here.)
Since this is a draft that hasn't made progress for a while, I will close this. Feel free to reopen or post a new PR if you wish to finish this feature.