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.
What should use these core events? I think reserving events is fine.
The other option is to reserve a generic "trampoline" event, which
basically is like a callout, in that you have a pointer to a function
call and an arg, and everything can repost them to a task.
I think we should have this regardless, but I'm not opposed to burning
events for something as critical as the networking stack, for example.
Sterling
