[interfacekit] Re: Registrar: towards design

.
>> 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.

Good point; in my "code", if some new BMessageRunner is
instantiated with a finer granularity than the base registrar
one, then this new runner won't be processed for an excessive
duration indeed.


>>      /*
>>              The way this class is declared in the original Be headers is

>>              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"?

A message to bedevtalk a couple months ago exhibited a way
to freeze all B_PULSE sendings (system-wide (!)) just by
doing this:


/*
gcc PulseBug.cpp -lbe  
*/

#include <app/Application.h>
#include <app/MessageRunner.h>

int main()
{
        BApplication app( "application/x.vnd-cedricd.pulsebug" );
        
        {
                BMessage m( 'bleh' );
                BMessageRunner runner( be_app, &m, B_INFINITE_TIMEOUT );
                snooze(3000000);
        }
        
        return 0;
}

Get a wild ride and frigten yourself (err..) for 3 seconds
as your deskbar does not update ..etc; and then things
get normal again when the app exits normally. If you abort
it with ^C (and the runner's dtor is never called) then the
system-hose is irreversible and you have to reboot.

I'm sure the-os-formerly-known-as-OpenBeOS won't have this
same bug now that it was rooted-up from the original BeOS ;-)

One more case to add to the testsuite, this inifite_timeout thinggie...



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

This is intriguing indeed.. APlayer has about 50 - let's say 100,
same league - MIME types to register, this is not la mer a boire...
The registrar should handle 100 BNode::WriteAttr()-somehting calls
quickly. Maybe it's the Tracker that's doing some extra wide
monitoring through BMimeType::StartWath something and monitoring
is slow....   dunno.


> 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.

IMHO both reading and writing have to be synchronized....

Think concurrence; like in other cases, e.g. Almost all of BWindow
code is "critical section" and thus protected by a "mutex" (ok,
an Lock() call) even if someone wants to read CurrentMesage()
and someone else wants to Show() they still ahve to be serialized...
  Or the example of the kernel's syslog: all concurrence is handled
by the syslog so that you don't get half a log line from an
app and then the other half from another app ...etc    If applications
were writing directly fwrite("/var/syslog") rather than go
through the daemon that would wreak havoc...

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