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