On Tue, Jul 25, 2017 at 03:20:46PM -0700, Vipul Rahane wrote: > Hello, > > While working on the sensors framework, I found a limitation which > seems to be system wide and should be discussed before coming to a > consensus. > > By default all packages run on the default eventq. Generally, > everybody uses the default eventq since that’s what initialization > functions use which get called from sysinit via the package > initialization functions. We have not seen many use cases where the > app would like to change the eventq. If a developer would like to > change the eventq he/she would have to modify the initialization > function to do this. As we have it today, we allow setting eventqs in > the app by exposing an API to set eventqs for a package. It is kind of > bug prone as any timers initialized earlier would still keep using the > old eventq. > > I can think of three possible solutions to this problem: > > 1. Reinitializing timers and resetting them in the evq_set() > functions. > This solution however seems a bit counter intuitive as setting the > eventq also resets the timers. > > 2. Allow reinitialization of modules so that initialization Vs > re-initialization can be differentiated. This would make resetting > timers explicit. > > Initialization generally does the following: > - Initialize timers, callouts by setting the eventq > - Create and Initialize mutexes > - Initialize module specific parameters(e.g.: Module Eventq, Base > timestamps, etc) > > Re-initialization would do the following: > - Set module eventq > - Re-initialize timers, callouts by stopping the timers, callouts and > resetting them. > > IMO, 2. is the best solution.
I wouldn't be surprised if a lot more packages have this same problem. Option 2 sounds good to me. I presume each package's set-eventq function would be removed from its public interface. When the application wants to move a package to a different task, it would call the reinitialize function instead? Chris
