xiaoxiang781216 commented on PR #8937: URL: https://github.com/apache/nuttx/pull/8937#issuecomment-1496952148
> > But, this change doesn't work for SMP, and the thread may suspend and switch to new thread even you hold critical section since the thread may block self or wake high priority thread inside sync function, the context switch happens immediately in both cases. > > So, what is the proper way to handle this? > Actually, if the safe reboot is the goal, you can't reboot immediately anyway, if there is some cache in the file system need to be flushed out. > Although, to be honest, `reboot_notifier_call_chain()` is quite terrible. I have seen problems within the notifier that prevent the system from rebooting (haven't found the root cause yet), > reboot_notifier_call_chain self doesn't block anything, it's the callback block you. > And generally, with this notifier, there is no way to reboot the system immediately. Like, **now**, without executing anything, without delay, without waking up any threads. > > Also, it seems like it breaks the system architecture. This is a call to the "board", why is it messing with the FS? > I don't see there is any design problem here. board code doesn't call fs directly, which just notify the reboot and the callback registered by fs do the sync. Do you have better approach? > If someone wants a "clean" reboot, why not call `sync()` outside of the _board_ reboot? And then just do the reboot? And of course handle the concurrency problems, externally, as the application dictates. > If sync hang in board_reboot, it likely will hang if you call sync from userspace directly. > Or maybe have a board interface, that just reboots the system, and an OS interface that performs a "graceful" shut-down? -- 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]
