Timers, scheduling and Ruby

Discussion in 'Ruby' started by Damphyr, Nov 30, 2006.

  1. Damphyr

    Damphyr Guest

    Ok, since the original post migh just appear in a month's time, lets
    rephrase the question:

    I'm building a set of tools for build and test management (yes, yes, it
    will do DamagaControl's work and yes, yes it will be released...and yes,
    this is code that is used in real-life projects - it's all so close to
    public alpha status).
    Now, I can leave scheduling to cron (or at/schtasks), but it would be
    nice to provide an interface so that scheduling can be set in the
    application via some administration console.
    Behind the scenes cron manipulation is too flaky for my tastes (and for
    windows I would need a separate implementation).
    So, is there a library that will give me timers, a nice way to configure
    them and a nice event driven interface? :)
    Cheers,
    V.-
    --
    http://www.braveworld.net/riva
     
    Damphyr, Nov 30, 2006
    #1
    1. Advertising

  2. Damphyr wrote:
    > Ok, since the original post migh just appear in a month's time, lets
    > rephrase the question:

    You've discovered a chronosynclastic infundibulum, apparently. :)
    >
    > I'm building a set of tools for build and test management (yes, yes,
    > it will do DamagaControl's work and yes, yes it will be released...and
    > yes, this is code that is used in real-life projects - it's all so
    > close to public alpha status).
    > Now, I can leave scheduling to cron (or at/schtasks), but it would be
    > nice to provide an interface so that scheduling can be set in the
    > application via some administration console.
    > Behind the scenes cron manipulation is too flaky for my tastes (and
    > for windows I would need a separate implementation).
    > So, is there a library that will give me timers, a nice way to
    > configure them and a nice event driven interface? :)
    > Cheers,
    > V.-

    Event Machine?

    --
    M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
    http://borasky-research.blogspot.com/

    If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
     
    M. Edward (Ed) Borasky, Nov 30, 2006
    #2
    1. Advertising

  3. On Nov 30, 2006, at 7:51 AM, Damphyr wrote:

    > Behind the scenes cron manipulation is too flaky for my tastes (and
    > for windows I would need a separate implementation).
    > So, is there a library that will give me timers, a nice way to
    > configure them and a nice event driven interface? :)


    I've wanted this myself. I wonder if we could get it down to Ruby
    Quiz size...

    James Edward Gray II
     
    James Edward Gray II, Nov 30, 2006
    #3
  4. Damphyr

    Damphyr Guest

    M. Edward (Ed) Borasky wrote:

    >> So, is there a library that will give me timers, a nice way to
    >> configure them and a nice event driven interface? :)
    >> Cheers,
    >> V.-

    > Event Machine?

    I'm not sure about this. EventMachine seems geared towards networking.
    I just want a class that will tick away on it's own thread and fire
    events at designated time points.
    My requirements include firing at intervals (every thirty minutes, every
    two days), once (in thirty minutes, on 1/1/2007 at 0:00 etc.) and I
    would like to have named events if possible.
    Getting the events should be as simple as observing the timer.
    So will anybody save me the work or do I have to code the beast?
    Cheers,
    V.-

    --
    http://www.braveworld.net/riva
     
    Damphyr, Nov 30, 2006
    #4
  5. Damphyr

    Rob Sanheim Guest

    On 11/30/06, Damphyr <> wrote:
    > I'm not sure about this. EventMachine seems geared towards networking.
    > I just want a class that will tick away on it's own thread and fire
    > events at designated time points.
    > My requirements include firing at intervals (every thirty minutes, every
    > two days), once (in thirty minutes, on 1/1/2007 at 0:00 etc.) and I
    > would like to have named events if possible.
    > Getting the events should be as simple as observing the timer.
    > So will anybody save me the work or do I have to code the beast?
    > Cheers,
    > V.-


    I have nothing worthwhile to add, other then that I've also definitely
    wanted something like this. rubyquiz?

    - rob
     
    Rob Sanheim, Nov 30, 2006
    #5
  6. Damphyr

    Guest

    On Fri, 1 Dec 2006, James Edward Gray II wrote:

    > On Nov 30, 2006, at 7:51 AM, Damphyr wrote:
    >
    >> Behind the scenes cron manipulation is too flaky for my tastes (and for
    >> windows I would need a separate implementation).
    >> So, is there a library that will give me timers, a nice way to configure
    >> them and a nice event driven interface? :)

    >
    > I've wanted this myself. I wonder if we could get it down to Ruby Quiz
    > size...


    i'm working on a library for this now. any request?

    -a
    --
    if you want others to be happy, practice compassion.
    if you want to be happy, practice compassion. -- the dalai lama
     
    , Nov 30, 2006
    #6
  7. On Nov 30, 2006, at 11:47 AM, wrote:

    > On Fri, 1 Dec 2006, James Edward Gray II wrote:
    >
    >> On Nov 30, 2006, at 7:51 AM, Damphyr wrote:
    >>
    >>> Behind the scenes cron manipulation is too flaky for my tastes
    >>> (and for windows I would need a separate implementation).
    >>> So, is there a library that will give me timers, a nice way to
    >>> configure them and a nice event driven interface? :)

    >>
    >> I've wanted this myself. I wonder if we could get it down to Ruby
    >> Quiz size...

    >
    > i'm working on a library for this now. any request?


    Ara, you just plain rock.

    My biggest request: a sane way (read: not-cron-like) to schedule
    events. ;)

    James Edward Gray II
     
    James Edward Gray II, Nov 30, 2006
    #7
  8. Damphyr

    Guest

    On Fri, 1 Dec 2006, James Edward Gray II wrote:

    > My biggest request: a sane way (read: not-cron-like) to schedule events. ;)


    how bout this as the time spec?

    http://runt.rubyforge.org/

    ??

    -a
    --
    if you want others to be happy, practice compassion.
    if you want to be happy, practice compassion. -- the dalai lama
     
    , Nov 30, 2006
    #8
  9. Damphyr

    Damphyr Guest

    James Edward Gray II wrote:
    >
    > My biggest request: a sane way (read: not-cron-like) to schedule
    > events. ;)

    How about stealing from schtasks
    (http://www.microsoft.com/resources/...p/all/proddocs/en-us/schtasks.mspx?mfr=true)?
    (ducks away and hides)
    It doesn't have to be so convoluted.

    Define the task like this

    class ScheduledTask
    attr_reader :name,:schedule,:schedule_params
    end

    Schedule is one of :minute, :hourly, :daily, :weekly, :monthly, :yearly

    then according to schedule you have different options.
    Universal options:
    :eek:nce to generate the event only once. It's not there, then we get repeats.
    :start_time to define when to start counting. If you leave it undefined
    the timer starts immediately. If you define it, it should be in the future.
    interval (after x minutes/hours/days/weeks/months/years an event will be
    generated. if once is defined it runs once x /whatever/ after start_time)

    An option valid for weekly and monthly can be :day, where you can
    specify the day of the week (1-7) or month (1-31).

    Would that be simple enough?
    Cheers,
    V.-
    --
    http://www.braveworld.net/riva
     
    Damphyr, Nov 30, 2006
    #9
  10. On 11/30/06, Damphyr <> wrote:
    > M. Edward (Ed) Borasky wrote:
    >
    > >> So, is there a library that will give me timers, a nice way to
    > >> configure them and a nice event driven interface? :)
    > >> Cheers,
    > >> V.-

    > > Event Machine?

    > I'm not sure about this. EventMachine seems geared towards networking.
    > I just want a class that will tick away on it's own thread and fire
    > events at designated time points.
    > My requirements include firing at intervals (every thirty minutes, every
    > two days), once (in thirty minutes, on 1/1/2007 at 0:00 etc.) and I
    > would like to have named events if possible.
    > Getting the events should be as simple as observing the timer.
    > So will anybody save me the work or do I have to code the beast?
    > Cheers,
    > V.-
    >
    > --
    > http://www.braveworld.net/riva
    >
    >



    Try this in EventMachine:

    require 'rubygems'
    require 'eventmachine'

    EventMachine.run {
    EventMachine.add_periodic_timer(60) {
    # The code in this block gets executed every sixty seconds
    }
    EventMachine.add_periodic_timer(3600) {
    # The code in this block gets executed once an hour
    }
    }


    You can read the timer definitions out of a config file, configure
    them dynamically on the fly, or build them with a GUI.
     
    Francis Cianfrocca, Nov 30, 2006
    #10
  11. On Nov 30, 2006, at 2:30 PM, wrote:

    > On Fri, 1 Dec 2006, James Edward Gray II wrote:
    >
    >> My biggest request: a sane way (read: not-cron-like) to schedule
    >> events. ;)

    >
    > how bout this as the time spec?
    >
    > http://runt.rubyforge.org/
    >
    > ??


    Ah yes, I looked into Runy recently when someone use it to solve a
    Ruby Quiz. Neat stuff. Plus, if we want additions we can just patch
    them into Runt. I like it.

    James Edward Gray II
     
    James Edward Gray II, Dec 1, 2006
    #11
  12. Damphyr

    Damphyr Guest

    James Edward Gray II wrote:
    > On Nov 30, 2006, at 2:30 PM, wrote:
    >
    >> On Fri, 1 Dec 2006, James Edward Gray II wrote:
    >>
    >>> My biggest request: a sane way (read: not-cron-like) to schedule
    >>> events. ;)

    >>
    >> how bout this as the time spec?
    >>
    >> http://runt.rubyforge.org/
    >>
    >> ??

    >
    > Ah yes, I looked into Runy recently when someone use it to solve a Ruby
    > Quiz. Neat stuff. Plus, if we want additions we can just patch them
    > into Runt. I like it.

    Nice ideas. I still need a UI wrapper for this code though and a way to
    configure events that is non-programmer friendly.
    And ofcourse the little ticker in it's thread that checks the schedule
    and fires the events.

    Cheers,
    V.-
    --
    http://www.braveworld.net/riva
     
    Damphyr, Dec 1, 2006
    #12
  13. Damphyr

    Pit Capitain Guest

    schrieb:
    > how bout this as the time spec?
    >
    > http://runt.rubyforge.org/


    Ara, this would be nice, but I think it's difficult to determine the
    time of the next event with Runt's temporal expressions. I'm sure you
    don't want to call Runt::TExpr#include? every n seconds.

    Regards,
    Pit
     
    Pit Capitain, Dec 1, 2006
    #13
  14. Damphyr

    Guest

    On Fri, 1 Dec 2006, Pit Capitain wrote:

    > schrieb:
    >> how bout this as the time spec?
    >>
    >> http://runt.rubyforge.org/

    >
    > Ara, this would be nice, but I think it's difficult to determine the time of
    > the next event with Runt's temporal expressions. I'm sure you don't want to
    > call Runt::TExpr#include? every n seconds.


    indeed. this is the only major design flaw. still, if one assumes a
    granualrity of not more than 60s (ala cron) then this approach isn't too bad.
    between the dates/include methods one can determine apriori if an event should
    be scheduled for the next minute 'tick'.

    i'm assuming there is either a solution implied in the code or that one can be
    added without too much trouble - the bulk of the work has already been done in
    this lib, so even if it isn't there now, i'm sure a solution will present
    itself.

    now. what do you suggest?

    ;-)

    -a
    --
    if you want others to be happy, practice compassion.
    if you want to be happy, practice compassion. -- the dalai lama
     
    , Dec 1, 2006
    #14
  15. Damphyr

    Pit Capitain Guest

    schrieb:
    > now. what do you suggest?
    >
    > ;-)


    I, too, think it should be possible to add the missing functionality to
    Runt. Unfortunately I have no time to do it myself, so all I can say is:

    Go ahead ;-)

    Regards,
    Pit
     
    Pit Capitain, Dec 1, 2006
    #15
  16. Damphyr

    Tim Pease Guest

    On 12/1/06, <> wrote:
    > On Fri, 1 Dec 2006, Pit Capitain wrote:
    >
    > > schrieb:
    > >> how bout this as the time spec?
    > >>
    > >> http://runt.rubyforge.org/

    > >
    > > Ara, this would be nice, but I think it's difficult to determine the time of
    > > the next event with Runt's temporal expressions. I'm sure you don't want to
    > > call Runt::TExpr#include? every n seconds.

    >
    > indeed. this is the only major design flaw. still, if one assumes a
    > granualrity of not more than 60s (ala cron) then this approach isn't too bad.
    > between the dates/include methods one can determine apriori if an event should
    > be scheduled for the next minute 'tick'.
    >
    > i'm assuming there is either a solution implied in the code or that one can be
    > added without too much trouble - the bulk of the work has already been done in
    > this lib, so even if it isn't there now, i'm sure a solution will present
    > itself.
    >
    > now. what do you suggest?
    >


    Runt looks nice. Another package is Chronic. It was part of the
    natural language processing presentation at RubyConf this year. All
    Chronic does, though, is take human "fuzzy" times and turns them into
    actual Time objects.

    Chronic.parse "next Thursday at seven am" #=> Time object

    http://rubyforge.org/projects/chronic/

    What is needed to make Runt work for a scheduler is a next_time method
    that would return the next Time that this event should happen given
    Time.now. The scheduler then maintains a queue of the "next time" for
    all events and pulls them from the queue in order. When an event runs,
    the last thing it does is pulls the next_time from Runt and adds that
    to the queue (in the proper location). The scheduler thread then
    sleeps for N seconds where N is the time till the next event in the
    queue needs to happen.

    So, maybe a combination of Chronic (to get the nice human readable
    format) and Runt (to keep track of recurring events) would work?

    TwP
     
    Tim Pease, Dec 1, 2006
    #16
  17. Damphyr

    Guest

    On Sat, 2 Dec 2006, Tim Pease wrote:

    >> now. what do you suggest?

    >
    > Runt looks nice. Another package is Chronic. It was part of the natural
    > language processing presentation at RubyConf this year. All Chronic does,
    > though, is take human "fuzzy" times and turns them into actual Time objects.
    >
    > Chronic.parse "next Thursday at seven am" #=> Time object
    >
    > http://rubyforge.org/projects/chronic/


    oh yeah - i'd forgotten about that. thanks.

    > What is needed to make Runt work for a scheduler is a next_time method that
    > would return the next Time that this event should happen given Time.now. The
    > scheduler then maintains a queue of the "next time" for all events and pulls
    > them from the queue in order. When an event runs, the last thing it does is
    > pulls the next_time from Runt and adds that to the queue (in the proper
    > location). The scheduler thread then sleeps for N seconds where N is the
    > time till the next event in the queue needs to happen.


    i don't think that'll quite work because:

    scheduler.on(every_minute) do
    task_that_takes_five_minutes
    end

    of course threads can help, but it the scheduler allowed milli-second
    precision for firing events (why not) you'd have a race condition where new
    evnets might not be started because 'next time' was missing during the time we
    started the last one.

    rather, i think one must

    1) constrain even runner to check only every n seconds, ala cron

    2) have the event interalize the time iteration itself so it can start
    threads whenever it needs

    > So, maybe a combination of Chronic (to get the nice human readable format)
    > and Runt (to keep track of recurring events) would work?


    yeah. whatever solution comes out should definitely add nice syntax for
    common dates.

    cheers.

    -a
    --
    if you want others to be happy, practice compassion.
    if you want to be happy, practice compassion. -- the dalai lama
     
    , Dec 1, 2006
    #17
  18. Damphyr

    Tim Pease Guest

    On 12/1/06, <> wrote:
    > On Sat, 2 Dec 2006, Tim Pease wrote:
    >
    > >> now. what do you suggest?

    > >
    > > Runt looks nice. Another package is Chronic. It was part of the natural
    > > language processing presentation at RubyConf this year. All Chronic does,
    > > though, is take human "fuzzy" times and turns them into actual Time objects.
    > >
    > > Chronic.parse "next Thursday at seven am" #=> Time object
    > >
    > > http://rubyforge.org/projects/chronic/

    >
    > oh yeah - i'd forgotten about that. thanks.
    >
    > > What is needed to make Runt work for a scheduler is a next_time method that
    > > would return the next Time that this event should happen given Time.now. The
    > > scheduler then maintains a queue of the "next time" for all events and pulls
    > > them from the queue in order. When an event runs, the last thing it does is
    > > pulls the next_time from Runt and adds that to the queue (in the proper
    > > location). The scheduler thread then sleeps for N seconds where N is the
    > > time till the next event in the queue needs to happen.

    >
    > i don't think that'll quite work because:
    >
    > scheduler.on(every_minute) do
    > task_that_takes_five_minutes
    > end
    >
    > of course threads can help, but it the scheduler allowed milli-second
    > precision for firing events (why not) you'd have a race condition where new
    > evnets might not be started because 'next time' was missing during the time we
    > started the last one.
    >
    > rather, i think one must
    >
    > 1) constrain even runner to check only every n seconds, ala cron
    >


    You're still going to have the missed events problem with the runner
    regardless of the time granularity. If you only check every ten
    seconds but notifications take twenty, then a whole set of
    notifications are missed.

    Sounds like (regardless of using cron style runner or Runt "next time"
    conventions) missed notifications need to be handled in a predictable
    manner.
    1) just drop them
    2) send out an extra notification immediately
    3) queue up the missed notifications for the next time


    > 2) have the event interalize the time iteration itself so it can start
    > threads whenever it needs
    >


    Will this cause a slow thread death with lots and lots of events? The
    ruby thread scheduler might eat up all your processor trying to
    schedule 1000+ threads?

    At the last ruby group meeting, Nathan Witmer showed me a nice little
    "thread per notification" system he put together. It sounds very
    useful for this project of yours.

    My $0.02

    Blessings,
    TwP
     
    Tim Pease, Dec 1, 2006
    #18
  19. Damphyr

    Guest

    On Sat, 2 Dec 2006, Tim Pease wrote:

    >> rather, i think one must
    >>
    >> 1) constrain even runner to check only every n seconds, ala cron
    >>

    >
    > You're still going to have the missed events problem with the runner
    > regardless of the time granularity. If you only check every ten seconds but
    > notifications take twenty, then a whole set of notifications are missed.


    nah. you'd raise an error if events were scheduled at finer than 'n'. in
    cron it's simply not possible - same thing. alternatively you can merge into
    minute buckets.

    > Sounds like (regardless of using cron style runner or Runt "next time"
    > conventions) missed notifications need to be handled in a predictable
    > manner.


    > 1) just drop them
    > 2) send out an extra notification immediately
    > 3) queue up the missed notifications for the next time


    agreed. i'd add:

    4) call user handler - specification possible at event creation

    there is some uber cron thingy on macs that handles this i think... anyone?



    >> 2) have the event interalize the time iteration itself so it can start
    >> threads whenever it needs
    >>

    >
    > Will this cause a slow thread death with lots and lots of events? The
    > ruby thread scheduler might eat up all your processor trying to
    > schedule 1000+ threads?


    it sure could. i'm of the opinion though, that users should be allowed to
    shoot themselves in the foot - if you want to schedule 40,000 events per
    second then fine, maybe your quantum computer can actually handle it! ;-)

    a warning or hard/soft limits might be a good compromise.

    > At the last ruby group meeting, Nathan Witmer showed me a nice little
    > "thread per notification" system he put together. It sounds very useful for
    > this project of yours.


    link?

    -a
    --
    if you want others to be happy, practice compassion.
    if you want to be happy, practice compassion. -- the dalai lama
     
    , Dec 1, 2006
    #19
  20. Damphyr

    Guest

    On Sat, 2 Dec 2006, Michael Guterl wrote:

    >> [1] http://en.wikipedia.org/wiki/Launchd

    >
    >
    > Sorry everyone, I had no idea this paste would turn out so hideous.



    heh. no problem. you were right too.

    -a
    --
    if you want others to be happy, practice compassion.
    if you want to be happy, practice compassion. -- the dalai lama
     
    , Dec 1, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shawn B.
    Replies:
    2
    Views:
    552
    Scott Allen
    Apr 28, 2005
  2. Lindsay
    Replies:
    3
    Views:
    822
    red floyd
    Jul 12, 2005
  3. nkb
    Replies:
    2
    Views:
    124
  4. vincent
    Replies:
    0
    Views:
    176
    vincent
    Jun 22, 2005
  5. Bishnu Das
    Replies:
    1
    Views:
    394
    John Mettraux
    Mar 24, 2008
Loading...

Share This Page