xiaoxiang781216 edited a comment on pull request #1501:
URL: https://github.com/apache/incubator-nuttx/pull/1501#issuecomment-670150965
> > It's better to prepare a concrete change before discussing. The PR
doesn't conflict with discussion but help people understand the problem.
>
> You should at least first understand the reason why the OS uses all
pre-allocated memory resources. This is required by certain safety standards:
After the booting, these standards prohibit any dynamic allocation of memory.
We need to conform to this standard. This is currently implemented for most OS
structures.
>
> Messages are a little different, there is a fixed pool there too, but
additional messages can be allocated dynamically if necessary. But, in general,
the no dynamic-allocation-after-initialization requirement must be supported.
Of course, I understand the pool usage: no body can forecast how fast
message/signal will generate/consume at runtime, the dynamic allocation is
required for message/signal and the preallocated pool can avoid the memory
fragment, allow interrrupt send message/signal and improve the performance.
But wdog is different from message/signal which usage is fixed: we can
directly embed wdog_s into the parent struct and bypass the allocation at all:
```
struct posix_timer_s
{
FAR struct posix_timer_s *flink;
uint8_t pt_flags; /* See PT_FLAGS_* definitions */
uint8_t pt_crefs; /* Reference count */
pid_t pt_owner; /* Creator of timer */
int pt_delay; /* If non-zero, used to reset repetitive
timers */
int pt_last; /* Last value used to set watchdog */
struct wdog_s pt_wdog; /* The watchdog that provides the timing
*/
^^^^^^^^^^^^^^^^
struct sigevent pt_event; /* Notification information */
struct sigwork_s pt_work;
};
```
It's much better than the current implementation: less memory and fast
speed. So please don't assume your design is always best.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
