Re: Changing eventq for a package

[Christopher Collins <ch...@runtime.io>]

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

Re: Changing eventq for a package

[Vipul Rahane <vi...@runtime.io>]

> On Jul 25, 2017, at 4:17 PM, will sanfilippo <wi...@runtime.io> 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 <vi...@runtime.io> wrote:
>> 
>> 
>>> On Jul 25, 2017, at 3:30 PM, Christopher Collins <ch...@runtime.io> 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
>> 
> 

Re: Changing eventq for a package

[will sanfilippo <wi...@runtime.io>]

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 <vi...@runtime.io> wrote:
> 
> 
>> On Jul 25, 2017, at 3:30 PM, Christopher Collins <ch...@runtime.io> 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
> 

Re: Changing eventq for a package

[Vipul Rahane <vi...@runtime.io>]

> On Jul 25, 2017, at 3:30 PM, Christopher Collins <ch...@runtime.io> 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