tinyos 中的事件是否在堆栈内部发出信号？
我想问一些我认为tinyos2编程手册中没有明确规定的问题。 当命令或任务发出接口事件信号时，是否立即调用连线函数（即在同一个调用堆栈中），或者这些发出信号的事件是否“发布”以供以后执行？
我倾向于认为是前一种，但只是为了澄清一下。
I wanted to ask something that I think is not clearly specified in the tinyos2 programming manual. When a command or task signals an interface event are the wired functions called immediately, i.e. in the same callstack, or are these signaled events "posted" for later execution?
I tend to believe it's the former one, but just to clarify it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
TinyOS 1 或 2 在这里没有什么区别 - 这是一个 nesC 问题。 一旦收到信号，立即开始执行。 但是，如果多个组件连接到一个接口，则执行会依次完成（也称为扇出）。
TinyOS 1 or 2 does not make a difference here - this is a nesC question. Upon signal, execution begins immediately. However, if multiple components are wired to an interface, execution is done one after another (aka. fan-out).
我只知道TinyOS v1，但我相信它们在这方面是相同的。
事件只是函数调用，因此与调用者在同一堆栈上执行。
如果需要发布某些内容以供稍后执行，则应将其作为任务来实现。 因此，需要执行长时间运行的工作来响应事件但又不想干扰中断延迟的事件使用者应该安排一个任务，并且该任务应该执行一点工作，然后安排一个任务来执行以同样的方式做更多的工作。
I only know TinyOS v1, but I believe they are the same in this regards.
Events are just function calls, and so execute on the same stack as the caller.
If something needs to be posted for later execution, it should be implemented as a task. So, event consumers that need to do long-running work in response to an event but don't want to interfere with interrupt latency should schedule a task, and that task should do a little bit of the work and then schedule a task to do more of the work in the same way.