Brad Campbell
Brad Campbell
> * we have an application that requires low latency, and while it is running it should only be preempted if there are certain interrupts pending (Ethernet or CAN for...
> As-is, this drops errors silently :(. But, we're hamstrung by the interface of the stabilized console driver here, which didn't have any way to report asynchronous errors on the...
I know this isn't as pressing because the previous PR happens to fix the issue in #3433, but I assume we still want this?
I guess let me know if I need to do anything for this PR? Otherwise hopefully it will be merged eventually as it is the fix for #3433.
This is still needed. The side effect of the other pr is that the app works without this, but this fix is still correct.
I think we want something like this. This yield-for makes mixing async and sync code in userspace easier. Currently, it is fairly easy to write _all_ async or _all_ sync...
> ```rust > allow(); > command(); > // Can't do this: ret = yield_for_blocking(UPCALL_ID, &arg1, &arg2, &arg3); > int subscribe_num_and_arg1 = SUBSCRIBE_NUMBER; > ret = yield_for_blocking(DRIVER_NUMBER, &subscribe_num_and_arg1, &arg2, &arg3); >...
Yes that is what I was imagining.
> > Note that libtock-rs today only even allows one outstanding callback > > Why is that limitation in place? That's a pretty crippling limitation for a lot of applications...
What is the usecase for calling subscribe and using `Yield-WaitFor-CallbackIfPresent`? Maybe writing async code with ordering semantics where the code can know which order the callbacks will happen?