Proposed 1.0 semantics specification

[Kees Jongenburger]

Thanks Casey for starting this disc

On Sun, Jun 14, 2009 at 9:57 PM, Casey Dahlin<cdahlin at redhat.com> wrote:
> This is my attempt to record and formalize Scott's description to me of
> the way Upstart 1.0 should behave. Its not complete and need some
> review, but there's a critical mass there now and I think its time to
> draw attention to it.
>
> http://upstart.ubuntu.com/wiki/CaseyDahlin/NewInternalSemantics

Here are my first notes:
Events:
>An event in Upstart is simply a particular point in time. It can be "3pm Thursday" or "The moment we first found out a network card >was plugged in." In the case of the first example, Upstart can detect that "3pm Thursday" has arrived by watching the system time. >In the case of the second, some external application (in this case likely device kit) would have to notify Upstart that the event >occurred.

The current upstart is strictly event driven. there might be some
timeouts in the code to handle process states and such but I don't
think upstart should monitor time or anything. I event think that the
current events already have to much information /variable in them

The initial idea why I started using upstart is because it could
(compared to system V) be in multiple states at the same time
"network" and "single_user" and there was no assumption about one
level being lower then the others

>A particular occurrence of an event may have a set of environment variables associated with it indicating details
>of that occurrence. In our network card example, it might contain the name of the new network device.

This does sound nice but the can not be true. in case of things like
network card what one want to to might be to create an instance using
the "network card name" as instance indicator. to me this sound like a
factory but this concept doesn't exit in upstart


> Classes
There as probably much more required methods "on_start on_event
on_starting on_failed_dependency ..."

> States
I find this part very confusing and I see many "Waiting" and I don't get it :p
Anyway:
Within the upstart code there is a concept called the "goal" it
determines where a job is heading I think it is a confortable
way of telling "what the goal is" and the states to get there are easy
to follow.

> Operations on instances
you mention restart being a stop and start
This is in general not true. when a service is stopped the services
that depend on that service should stop(sometimes at least)
while a restart can be as simple as sending a HUP to the process
requesting is to reinitialize

I think signal or "bus_message" might be other things you want to send
to the instance.


>The Queue
>When an event occurs or something attempts to call a method on one of Upstart's objects, this action is placed at the tail of a >Queue. Upstart processes actions from the head of the queue, one at a time. This has an effect of serialization; we do not have to >consider the idea of two events or method calls happening at once. During operation, Upstart may occasionally add one or more >events to the head of the queue to be processed immediately.

Like Scott mentioned the events are not  serialized a such. This is
because one single event generates new events
so they are not handled in a synchronous manner. The event can be
started to be consumed and then parked again to handle other events.
This is one part for the code that requires a little more thinking.


Thanks again for taking the time!