[interfacekit] Re: Registrar: towards design

> The registrar constructs an own BApplication which is aware of it being
> the registar and names the app looper port respectively. 
[...]
> * 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? 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. 

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. 

I suppose the event queue method could be done in a non-polled manner with 
snooze()ing as well, but it seems like it'd be a bit more complicated.

> The MIME functionality implemented in a separate BLooper (main=5Fmime)
> consists of:
> 
> * database access: at least writing to and monitoring it, maybe also
> reading.

After Cedric's comments, I'm really beginning to think we're not going to 
gain much by moving read access into the registrar vs. how much we'll lose 
performance-wise. I looked at the OpenBFS code to try and figure out how much 
locking actually occurred for concurrent read-only access. It looks like it's 
very little, but I sent off an email to Axel asking for his take on the matter

> So what should be done next, is to make a list of all concrete tasks
> and to design communication protocols. Then a concrete design of the
> registrar's data structures follows...

I believe everything else seemed good to me. Nice research job. :-)

-Tyler

Other related posts: