Re: r6796 introduced possible memory leak in os/timer.c
Uwe Bonnes <bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org> Sun, 17 Jan 2021 21:50:34 +0100
| Newsgroups | gmane.comp.hardware.microcontrollers.ethernut |
|---|---|
| Message-ID | <[email protected]> |
Philipp Burch writes: > Hi Uwe! > > On 16.01.21 19:54, Uwe Bonnes wrote: > > > > Just a short comment: I feel uneager at all that run-time allocation/ deallocation happens at all. > > > > > > Indeed. Especially that timers need heap memory in all kinds of OS > sleeps is not really nice. With the implemented NutTimerHandleStart(), > it would probably be possible to use a single pre-allocated timer > structure per thread. But I don't really feel comfortable with hacking > in the innermost parts of Ethernut. I neither. But I wanted a possibility to get rid of the runtime heap de/allocation. > > Considering the change done in r6796: Do you know why tn_flags was > implemented as a uint32_t? Since Ethernut also targets 8-bit platforms, > it seems somewhat inefficient to add a 32-bit value for a single bit to > one of the core OS structures. > You missed the " by you" in "Do you know why tn_flags was implemented as a uint32_t" ;-) I did not think of our poor memory starving AVR8 architecture. Changing flags to uint8_r should do no harm (famous last words). Where did you apply 6917 and 6918. "git svn rebase" only gives me Ole's change for 6916. Please either apply yourself to master or tell me to do so. Bye -- Uwe Bonnes bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 --------- _______________________________________________ http://lists.egnite.de/mailman/listinfo/en-nut-discussion