[interfacekit] Re: Registrar: towards design

> Late reply...
> >> [...]
> >> > * timer functionality: BMessageRunner management. B=5FPULSE 
> messages=3F A
> >> > separate thread (timer=5Fthread) is responsible for sending the
> >> > notifications at the right time. An event queue is the common 
> > > > data
> >> > structure.
> >> 
> >> Sounds reasonable, although wouldn't that involve a lot of polling 
> that we 
> >> might want to avoid?
> 
> Not sure why 'polling' was invoked there.. (vade retro satanas :-).
> The 'entities' of code involved client/server are, as I see it,
> the ctor and destructor of BMessageRunner, and its setters, which are
> one-time shots, and server-side, the timer_thread itself which has
> all the data it needs locally (does not need to query the
> client for its timer-frequency ..etc)

Yep.

> >Fortunately not. :-)
> >The typical strategy for such tasks is to time out on a semaphore. 
> > This
> >way it is even simple to notify the thread about updates by just 
> releasing
> >the semaphore.
> 
> Once "you" (the timer thraed) have all the data at hand, you may
> either do a 
>   for()
>   {
>      snooze(granularity_length?)
>      analyse_tables_and_fire_if_necessary()
>   }
> (maybe that's what was thought of about polling)

I guess, something like this was what Tyler originally had in mind.

> or be even more smart and further reduce the CPU usage
> by never doing a "NOP" for() iteration, but only useful ones:
> 
>   for()
>   {
>      analyse_tables_and_fire()   // 
> ASSERT(we_did_fire_0_or_more_here)
>      wake_up_time = 
>          compute_next_time_we_have_to_fire_a_timer_from_tables()
>      snooze_until(wake_up_time)
>   }

And that is similar to what I have in mind. Aside from that instead of 
snooze_until() I would use acquire_semaphore_etc(sem, 1, 
B_ABSOLUTE_TIMEOUT, wake_up_time), where sem is a semaphore that is 
only released when the event queue had been updated. That allows in 
particular to insert a new event before the first event.

> Threads are not cheap in the current implementation of BeOS in
> that, running out of them system-wide is a well known way of crashing
> the OS. Dunno about NewOS.
> 
> Don't call me Machiavel just yet, but I'm thinking that
> quotting my already done "naive implementation" of BMEssageRunner,
> complying exactly with the above, would be the best way to digust
> you and ensure you guys really come up with something better and
> as superior as the actual BeOS implementation :-).

We will at least try our best. :-)

[...]
>       /*
>               The way this class is declared in the original Be headers is
>               quite odd: the only member variable is "int32 fToken", like
>               if it was managed server-side maybe, and not memorized
>               in the client code... Anyway, we have a pure client 
> implementation:
>               
>               UPDATE:
>               ok this is because BMessageRunners are handled by the roster
>               under BeOS, as hinted at by The Book and the infamous "BRS 
> Pulse bug".
>       */

Out of curiosity: what is the "BRS Pulse bug"?

[snipped the scary code ;-)]

> [MIME database]
> 
> One thing *i*'d love to see fixed in BeOS is the way
> the whole MIME database is read &w rite locked for a couple
> seconds wehn e.g. APlayer or Soundplay start up and are configured
> to register their mime types: the whole OpenTracker is frozen
> (visible if you change workspaces) which is annoying.
>
> But I guess it's the registrar's way of encofrcing consistency
> and serializing accesses as discussed and thus will have to
> remain that way :/

That is interesting, especially because I don't understand the reason 
for this problem. On one hand I can't see, why registering the MIME 
type should take that long, and on the other hand, if the Tracker only 
reads the database, then -- as I wrote in an earlier message -- the 
database is read directly, i.e. without contacting the registrar. Maybe 
there is some locking mechanism I haven't seen yet.

CU, Ingo

Other related posts: