[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)


>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)
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)
  }


>> I'm not sure if this would be feasible (are threads 
>> cheap enough?), but how about creating a new thread to match each 
>> BMessageRunner that:
>> 
>> + snooze()s itself the appropriate interval
>> + fires off the message when it wakes back up 
>> + decrements its count, checking if it's done (if appropriate)
>> + snooze()s itself again, etc etc etc. 

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 :-).  Here comes the
(tested with /boot/apps/Pulse and working but as I said, naive) code:



#ifndef B_MESSAGE_RUNNER_H_
#define B_MESSAGE_RUNNER_H_

<snip>
private:  // data
        /*
                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".
        */
        
        // ctor- (and setter-) set data.
        BMessenger mgerTarget;
        BMessage msgCopy;
        bigtime_t sendingInterval;
        int32 sendingCount;
        
        // thread
        thread_id runnerThread;
};


#endif  // pragma once




The .cpp:

<snip>
int32 BMessageRunner::sender_thread( void * this_pointer )
{
        BMessageRunner * This = static_cast<BMessageRunner*>( this_pointer );
        
        for(;;)
        {
                snooze_until( system_time() + This->sendingInterval, 
B_SYSTEM_TIMEBASE 
);
                
                This->mgerTarget.SendMessage( &This->msgCopy );
                
                if( This->sendingCount >= 0 )
                {
                        This->sendingCount--;
                        
                        if( This->sendingCount <=0 )
                                // finito.
                                break;
                }
                // else we're sending ad infinitum.
        }
        
        return 0;
}





>> That way we're not polling the event queue all the time to see who 
gets 
>> updated next and when; we just let the kernel (who's already 
responsible for 
>> doing a bunch of that anyway) handle it. 

polling: just understood. Ignore my previous remark.


>That should work, but the number of threads might become relatively
>large (especially if the B_PULSE messages have to be sent from the
>registrar too).

BView::Pulse() is used under BeOS for each BTextView/BTextControl
(think insertion carret), Tracker, Deskbar, other purposes for each
app ..etc, it seems the extra engineering that Be did is worth it.


[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 :/

--
PGP key: http://cdegea.free.fr/degea_kagi_pubkey.txt | BeDev E-16870
"What's oil got to do, got to do with it" -- F02 Chorus

Other related posts: