> On Jul 25, 2017, at 4:17 PM, will sanfilippo <[email protected]> wrote: > > 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?
I see what you mean. It is a possible solution, but what would be required in this case is adding support to sysinit to take the eventq as a parameter without it being hardcoded, default being using the default eventq. I can see a use case for having a reinit but as you say I cannot see a use case where someone would want to change the eventq at runtime. - Vipul > > 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 >> >
