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
