> On Jul 25, 2017, at 8:08 PM, will sanfilippo <[email protected]> wrote:
> 
> +1 to remove start events.
> 
>> On Jul 25, 2017, at 3:43 PM, Christopher Collins <[email protected]> wrote:
>> 
>> Hello all,
>> 
>> Vipul's email about the default event queue reminded me of another
>> nagging issue involving tasks and queues: start events.  A package has
>> two initialization phases:
>> 
>>   1. sysinit
>>   2. start
>> 
>> The sysinit phase is executed from main() via a call to sysinit().
>> 
>> The start phase is implemented with an event that gets enqueued to the
>> package's eventq.  When it gets processed, this event executes the
>> package's start function.  If a new eventq is assigned to the package
>> before its start event has been processed, the event gets moved to the
>> new eventq.
>> 
>> Having two initialization phases made sense when they were first
>> introduced.  Back then, sysinit occurred before the OS scheduler
>> started, and it was desirable to delay some initialization until after
>> the OS was running.
>> 
>> Nowadays, the OS starts before main() even gets called, so there is
>> really no need for a second phase.  Furthermore, these phases aren't
>> even separate anymore.  If a package runs in a high priority task, its
>> start event will preempt the default task as soon as the package gets
>> initialized, and it will run before other packages have even been
>> initialized.
>> 
>> I propose that we remove start events.  Package's should just do all
>> their initialization in their sysinit function.  If some part of the
>> initialization needs to be delayed, it should be moved to a second
>> sysinit function with a greater stage number.

+1 for removing start events. If some part of the initialization needs to be 
delayed, it should be moved to a second sysinit function with a greater stage 
number or be done in the app after sysinit().

>> 
>> All thoughts are appreciated.
>> 
>> Thanks,
>> Chris
> 

Reply via email to