Re: [PR] sched: add a reference count to the TCB to prevent it from being deleted. [nuttx]

[via GitHub]

anchao commented on PR #17468:
URL: https://github.com/apache/nuttx/pull/17468#issuecomment-3832935183

   > > One more update for you all:
   > > 
   > > 1. In the process of promoting NuttX right now, most business 
stakeholders have extremely high requirements for kernel performance and will 
opt for Zephyr as their first choice. Developers also have numerous doubts 
about the stability and performance of the NuttX kernel.
   > > 2. When working on your internal solutions, you’d better research how 
other companies have implemented their corresponding solutions. Even 
Bestechnic, your Tier 1 supplier, does not recommend using your framework for 
headphone and Wi-Fi/BT module solutions.
   > > 3. The next-generation OS will be built on the first principles rather 
than being based on excessive assumptions. Any business implementations with 
poor performance or flaws should be phased out and optimized, instead of having 
the operating system do a great deal of unnecessary fallback work for them.
   > 
   > It just means we are encountering different usage scenarios. While 
enter_critical_section might work for very simple cases, But, nuttX needs to 
evolve.
   > 
   > Memory safety issues are not imaginary. Let's take the function 
nxsched_foreach as an example. We cannot guarantee that the tcb parameter 
passed to the handler is always valid. Neither enter_critical_section nor 
sched_lock can solve this problem. If the handler performs a wait operation, it 
will invalidate the entire critical section and the scheduling lock.
   > 
   > <img alt="image" width="506" height="443" 
src="https://private-user-images.githubusercontent.com/128452594/543571247-1c4f4e45-b4e6-4601-8392-5904b928f45e.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzAwMDkwODksIm5iZiI6MTc3MDAwODc4OSwicGF0aCI6Ii8xMjg0NTI1OTQvNTQzNTcxMjQ3LTFjNGY0ZTQ1LWI0ZTYtNDYwMS04MzkyLTU5MDRiOTI4ZjQ1ZS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjAyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIwMlQwNTA2MjlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03MmVmNjUyZjI1NGIyN2E0NTY4YTk5NmIzY2UzNTgxMTgxMWJmZTc4ZjkwNzNiYWEyNzE5YmEzODk0NTkwY2IyJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.MJe_5U7pw3Tw5MygYaEX0F8ya6uzxih_mA03pu5OpME";>
   
   <img width="862" height="564" alt="image" 
src="https://github.com/user-attachments/assets/86465017-a130-48de-bc30-7107d0964933";
 />
   
   Shouldn't we optimize the implementation here?


-- 
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: commits-unsubscr...@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org