aviralgarg05 commented on PR #18288: URL: https://github.com/apache/nuttx/pull/18288#issuecomment-3831451559
> > > @aviralgarg05 thank you for the logs! In the future, please include that information in your testing section. > > > Your explanation doesn't really make sense to me. Why does the idle task try to wait on a semaphore only in the LVGL demo? Doesn't this assertion indicate that the problem is with something in the LVGL configuration, since no other NuttX code encounters this issue? > > > > > > @linguini1 > > From what I understand, the Idle task in the simulator is running the host event loop (input/display), so it’s effectively behaving like a driver thread. Since these drivers use standard APIs, they’re protected by mutexes. > > Earlier, the assertion was basically asking “Am I calling a wait function?”, which meant even safe, instant atomic acquisitions were blocked. The fix changes that logic to instead ask “Am I actually going to sleep?”. > > With this change, it seems okay for the Idle task to grab a free semaphore through the fast/atomic path, since that doesn’t block and is safe. But if it tries to wait on a busy semaphore and goes down the slow path, we still panic — which keeps the safety guarantees intact. > > sem_wait shouldn't be called from interrupt/idle context regardless whether the wait really happen. @xiaoxiang781216 I understand, thank you for the clarification. The issue arises because the Simulator architecture currently relies on the Idle loop to pump host events (LVGL/SDL). This driver code inevitably triggers semaphore usage (e.g., via `syslog` or internal driver locks) when processing those events. If `sem_wait` (and ostensibly `sem_trywait`) are strictly forbidden in the Idle context, does this imply that the Simulator's event loop logic must be moved out of the Idle task and into a dedicated worker thread? I am happy to implement the preferred architectural fix if you can point me in the right direction. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
