PS: I’d be interested in what Will has to say w.r.t controller, which
may be an exception — given that it will have hard timing
requirements, and likely need to be a high priority task. My mail was
meant to address more “appy” (app-ish?) libraries.
On 31 Aug 2016, at 16:14, 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.
Sterling
