Removing "start events"

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

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.

All thoughts are appreciated.

Thanks,
Chris

Re: Removing "start events"

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

> On Jul 25, 2017, at 8:08 PM, will sanfilippo <wi...@runtime.io> wrote:
> 
> +1 to remove start events.
> 
>> On Jul 25, 2017, at 3:43 PM, Christopher Collins <ch...@runtime.io> 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
> 

Re: Removing "start events"

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

+1 to remove start events.

> On Jul 25, 2017, at 3:43 PM, Christopher Collins <ch...@runtime.io> 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.
> 
> All thoughts are appreciated.
> 
> Thanks,
> Chris