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
