From: Michael Guterl Date: 2006-12-02T07:09:02+09:00 Subject: Re: Timers, scheduling and Ruby ------=_Part_8837_27049236.1165010938593 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/1/06, Michael Guterl wrote: > > On 12/1/06, ara.t.howard@noaa.gov wrote: > > > > 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? > > > I believe you're referring to launchd. > http://developer.apple.com/macosx/launchd.html *The correct title of this > article is launchd. The initial letter is shown capitalized due to > technical > restrictions< > http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_%28technical_restrictions%29#Lower_case_first_letter > > > .* > > *"launchd* is a unified, open > source service > management< > http://en.wikipedia.org/wiki/Operating_System_service_management> > framework for starting, stopping > and managing daemons< > http://en.wikipedia.org/wiki/Daemon_%28computer_software%29>, > programs and > scripts. > It was introduced with Mac OS X > v10.4 > /Darwin v8.0, > and is licensed under the Apache > License. > Dave Zarzycki is credited > with > designing and maintaining launchd. > > The launchd daemon< > http://en.wikipedia.org/wiki/Daemon_%28computer_software%29>is > essentially a replacement for > init , > rc, > the init.d >and > rc.d scripts, > SystemStarter (Mac OS X), > inetdand > xinetd , > atd, > crond and > watchdogd >. > Apple has stated that it intends to eliminate all of the aformentioned > services in favor of launchd. As of OS X v10.4 Apple has moved most of the > processes handled by the previously mentioned daemons to launchd. By > consolidating all the launch services into one program, launchd > significantly shortens boot time on slow computers."[1] > [1] http://en.wikipedia.org/wiki/Launchd Sorry everyone, I had no idea this paste would turn out so hideous. >> 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 > > > > > > ------=_Part_8837_27049236.1165010938593--