So this may not be the most educated or popular opinion, but why cant we do this via the newt tool and the .yml files in the apps/<myapp> directory? I do not see a use case for changing this dynamically (or should I say “run time”? Yeah, I know...) but I can definitely see a use case for wanting to change this based on the app.
I am generally not a fan of generated code but we do specify a package init function; could we not specify a package event queue function or something similar and override it in the app? Will > On Jul 25, 2017, at 4:04 PM, Vipul Rahane <[email protected]> wrote: > > >> On Jul 25, 2017, at 3:30 PM, Christopher Collins <[email protected]> wrote: >> >> 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? > > Yes, that would be the case. > >> >> Chris >
