On Fri, Mar 4, 2011 at 7:32 AM, David Jencks <[email protected]> wrote: > I haven't found out how to start more than one feature at once. I would > think that having some way to start a feature asynchronously would be > useful, but I think adding a system beyond startlevel to determine bundle > start order is not likely to work well. > > When would it be a problem to start a bunch of features aysnchronously at > once?
Good question :) But it would definitely help in some situations to speed up the initial startup. Kind regards, Andreas > > thanks > david jencks > > On Mar 3, 2011, at 8:18 PM, Andreas Pieber wrote: > >> OK, another feature proposal for 3.0: >> >> I've the following "problem" with the OpenEngSB project right now. We >> have different features where some are optional, but if they are >> defined they could also start in parallel. E.g. assume you have >> feature A and feature B. Feature A requires some time to come up since >> it requires some time to get all blueprint services wired, BUT feature >> B does not need to wait till feature A is finished but could rather >> startup with feature A (as if they're defined in the same feature). >> >> I can think of two solutions for the problem >> >> 1) Define parallel startup in features.cfg. In Archlinux you have a >> Daemons array defined saying which services to start during the boot >> which looks something like: >> >> DAEMONS=(syslog-ng netfs crond dbus !network wicd @acpid @cups @ntpdate @mpd) >> >> This means now: first start syslo.. then netfs, then crond (one after >> the other, similar to our feature file), but you don't have to wait >> for acpid, cups, ntpdate to wait, start them up and go ahead (thats >> what the @means). >> >> I can think of the same for Karaf: >> >> A,@B >> >> which could mean: start feature A and feature B like they where the same >> feature >> >> 2) A different solution could be to add a new tag to the features.xml >> listing the features with which a feature could be started in parallel >> ---> >> >> Feature B could contain: >> >> <couldBeStartedTogetherWith><feature version...>A</feature><feature >> version...>OTHER_FEATURE</feature></couldBeStartedTogetherWith> >> >> ------------ >> I think it may be good to support borth options since the feature >> developer should now best with which features his feature could start >> in parallel, BUT the feature developer can not imagine each possible >> feature which could be started in parallel with his feature. >> >> So, WDYT? :) >> >> Kind regards, >> Andreas > >
