On 12/1/06, ara.t.howard / noaa.gov <ara.t.howard / noaa.gov> 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