Yeah, I can see why you chose OS_EVENT_TIMER. It is almost like we should rename that event type :-) But I agree with everything you say below; creating a new event type for this seems wasteful. I am not quite sure what you mean by "My concern there is that applications may want to add special handling for certain event types…”. Are you referring to the events that a package may require of an application?
Anyway, solving this generically is definitely what we need to do. Will > On Apr 18, 2016, at 10:06 AM, Christopher Collins <[email protected]> wrote: > > On Mon, Apr 18, 2016 at 09:43:35AM -0700, Christopher Collins wrote: >> On Mon, Apr 18, 2016 at 09:18:16AM -0700, will sanfilippo wrote: >>> For #2, my only “concerns” (if you could call them such) are: >>> * Using OS_EVENT_TIMER as opposed to some other event. Should all >>> OS_EVENT_TIMER events be caused by a timer? Probably no big deal… What >>> events are going to be processed here? Do you envision many host >>> events? >> >> Yes, I agree. I think a more appropriate event type would be >> OS_EVENT_CALLBACK or similar. I am a bit leery about adding a new OS >> event type for this case, because it would require all applications to >> handle an extra event type without any practical benefit. Perhaps >> mynewt could relieve this burden with an "os_handle_event()" function >> which processes these generic events. My concern there is that >> applications may want to add special handling for certain event types, >> so they wouldn't want to call the helper function anyway. >> >> The OS events that the host would generate are: >> * Incoming ACL data packets. >> * Incoming HCI events. >> * Expired timers. > > (I meant "process", not "generate"!) > > Oops... I went down a rabbit hole and forgot to address the main point > :). What we would *really* want here is something like: > * BLE_HS_EVENT_ACL_DATA_IN > * BLE_HS_EVENT_HCI_EVENT_IN > > However, the issue here is that the event type IDs are defined in a > single "number-space". If the host package reserves IDs for its own > events, then no other packages can use those IDs for its own events > without a conflict. The 8-bit ID space is divided into two parts: > > 0 - 63: Core event types (TIMER, MQUEUE_DATA, etc.) > 64+: Per-task event types. > > So, the options for the host package are: > 1. Reserve new core event IDs. This avoids conflicts, but permanently > uses up a limited resource. > 2. Use arbitrary per-task event IDs. This has the potential for > conflicts, and doesn't strike me as a particularly good solution. > 3. Use a separate host task. This allows the host use IDs in the per-task > ID space without the risk of conflict. > 4. Leverage existing core events. This is what I proposed. It avoids > conflicts and doesn't require any new event IDs, but it does feel a > bit hacky to use the TIMER event ID for something that isn't a timer. > > I think this might be a common problem for other packages in the future. > I don't think it is that unusual for a package to not create its own > task, but still have the need to generate OS events. So perhaps we > should think about how to solve this general problem. > > Chris
