> On Sep 1, 2016, at 9:36 AM, Sterling Hughes <[email protected]> wrote: > > Yeah - for sure libraries should be able to use tasks (just like > newtmgr and shell do today.) I'm more thinking as maintainers of > core, which method do we prefer for standard libraries. > > Does anyone disagree that we should change newtmgr and shell to > instead work more like the BLE host and run in the context of the > calling task, rather than allocate their own tasks? > > Cheers, > > Sterling > > On Wed, Aug 31, 2016 at 7:47 PM, Christopher Collins > <[email protected]> wrote: >> On Wed, Aug 31, 2016 at 04:14:51PM -0700, Sterling Hughes wrote: >>> Hey, >>> >>> I’ve been wondering how we should handle libraries in the OS, that >>> need to run in a task context, but don’t necessarily need their own >>> _dedicated_ task context. >>> >>> I think right now we have two approaches: >>> >>> - Create a library that takes an event queue, and expects to be called >>> within a task context, but doesn’t create it’s own task (example: >>> BLE host - >>> http://mynewt.apache.org/latest/network/ble/ini_stack/ble_parent_ini/) >>> >>> - Including that package creates its own task, and requires it to >>> operate in that context. (example: newtmgr - >>> https://github.com/apache/incubator-mynewt-core/blob/master/libs/newtmgr/src/newtmgr.c#L504) >>> >>> Personally, I think we should move the first approach taken by the >>> bluetooth host for all system libraries that require a task context to >>> operate. I don’t see any reason why you couldn’t run newtmgr and >>> BLE host in the same context, and save the RAM space by having a big app >>> task that keeps posting to its own event queue. >>> >>> What do folks think? I think while we’re revising system init, it >>> would be a good time to look at this, and come up with a consistent mode >>> of operation. >> >> I agree for the most part, but I can think of one potential issue with >> not assigning a dedicated task to a library: blocking operations. >> If the caller and the library use the same task, who unblocks the >> caller? I guess an ISR. >> >> I think "prefer not to use a dedicated task" would be a good convention. >> >> Chris
I don’t have a strong preference here, except less task stacks is better for RAM consumption. I don’t think needs to be tied to system init changes. The work needed for this seems orthogonal.
