xiaoxiang781216 commented on code in PR #17222: URL: https://github.com/apache/nuttx/pull/17222#discussion_r2454467323
########## include/nuttx/sched.h: ########## @@ -251,6 +251,7 @@ enum tstate_e TSTATE_TASK_RUNNING, /* READY_TO_RUN - And running */ TSTATE_TASK_INACTIVE, /* BLOCKED - Initialized but not yet activated */ + TSTATE_SLEEPING, /* BLOCKED - Waiting for wakeup or timeout */ TSTATE_WAIT_SEM, /* BLOCKED - Waiting for a semaphore */ TSTATE_WAIT_SIG, /* BLOCKED - Waiting for a signal */ Review Comment: > I don't think call stack is enough in this case: the running taskB want to know the reason why taskA is blocked, even though this case is hardly needed in real world. > The backtrace will show you whether the thread is blocking in xxx_sleep or sig_xxx. > Anyway I agree that users may just care whether the task is running or waiting, but I think kernel need to separate which object the task is waiting on so the kernel can do things differently according to this, Another problem is that each wait state has an entry in g_tasklisttable, but it's strange that the scheduler never modify TSTATE_SLEEPING list. > please check the code below, I think this is the main reason nuttx now have different wait state (I have planed to update the code below for the new task state: **TSTATE_SLEEPING** ): **TSTATE_WAIT_SEM/TSTATE_WAIT_SIG/TSTATE_WAIT_MQNOTEMPTY/TSTATE_WAIT_MQNOTFULL**: The origin code distinguish the wait state between semaphore, queue, etc..., because the scheduler need handle the wait list in the different way. But, we can reuse the signal wait list because sleep is a special case of wait signal. -- 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]
