You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Vipul Rahane <vi...@runtime.io> on 2017/07/25 22:20:46 UTC
Changing eventq for a package
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 would like to hear the community’s thoughts on this.
Regards,
Vipul Rahane
Re: Changing eventq for a package
Posted by 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
Posted by 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
Posted by 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
Re: Changing eventq for a package
Posted by 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