[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

5043: Re: [MUD-Dev] World Persistence, flat files v/s DB v/s ??

[Full Header] [Plain Text]
From: J C Lawrence <claw@under.engr.sgi.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Tue, 31 Mar 1998 16:49:43 -0800
References: [1]
Organization: Kanga.Nu
On Tue, 24 Mar 1998 20:54:54 PST8PDT 
Vadim Tkachenko<vt@freehold.crocodile.org> wrote:

> Matt Chatterley wrote:

>> Obvious disadvantage: What if there is never such a gap? Well,
>> statistically speaking, if it checks every 6 hours, it'll check 28
>> times a week (and these times will reflect the period at which it
>> last rebooted, so it will hit the same time again). Should it go a
>> period of y days with no reboot, it will reduce the frequency of
>> checks. At some time, the mud will be empty. :P

> I've implemented a different approach in the Jukebox: there is an
> idle tracker service, and every time you start to process something
> or end to process something, you reset your time count on that
> service, so you'd be notified if there was a delay after LAST
> action. This way, you don't have to wait 6 hours.

> Funny, the implementation is amazingly simple: there is a concept of
> the semaphore which throws the exception unless posted, and all the
> idle handling is right here:

> while ( isEnabled() ) 
> { 
>   try { 
>     // do nothing here, I'm not interested in posts 
>     idleSem.waitFor( timeout ); 
>   } 
>   catch ( SemaphoreTimedOutException ex ) 
>   { 
>     report_timeout(); 
>   } 
> }

Note: This is very close to the standard SysV alarm signal handling.

<<Apologies for grieviously long quote>>

--
J C Lawrence                               Internet: claw@null.net
(Contractor)                               Internet: coder@ibm.net
---------(*)                     Internet: claw@under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...