On Wed, Oct 25, 2023 at 5:16 AM Ville Juven <ville.ju...@gmail.com> wrote:
> Hi all, > > I noticed that when spawning a new task/process from a file in > nsh_fileapps, the scheduler is locked prior to calling posix_spawn(), which > does the file loading into memory etc. > > I noticed one issue with this; when the file size is large (in the order of > MB) the scheduler is locked for very long periods at a time, in the order > of hundreds of milliseconds. This sounds like a bug. The scheduler should not be locked during IO-bound operations, since there is no way to know how long they will take. Loading from flash could take hundreds of milliseconds (which is already terrible) but imagine a different scenario where loading from a network with connection problems outside of the device could lock the device for many seconds! More below... So my question is, is the scheduler lock strictly necessary in this case ? > The only reason I could surmise from the comment below is that waitpid is > not performed on a stale pid (or even a possibly re-taken pid ?): > > /* Lock the scheduler in an attempt to prevent the application from > * running until waitpid() has been called. > */ > > sched_lock(); > > A follow-up question obviously is, what happens if the scheduler lock is > removed ? Will something bad happen and if so, is there a way to mitigate > this (other than the sched_lock())? I have not studied the code but conceptually the file should be loaded (or other IO operations) and only when ready to perform scheduler operation the scheduler should be locked for the minimal length of time. More below... My reason for removing the scheduler lock is obviously that I lose all > real-time assurances of the OS when I'm starting a process, e.g. I start > losing sensor data during the process load time. This is exactly why the scheduler should not be locked for extended lengths of time. Nathan
