Thanks Casey for starting this disc On Sun, Jun 14, 2009 at 9:57 PM, Casey Dahlin<cdah...@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! -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
