[interfacekit] Re: Registrar: towards design

On Mon, 17 Jun 2002, Tyler Dauwalder wrote:

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

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.

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

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

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

Based on the semaphore technique it is not that complicated. We use such 
an event queue in eXposer and it works very well. I have no problem with
reusing this code for the registrar.

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

As you pointed out yourself we can implement it one way and switch to
another whenever we like. Let's just compare the two methods.
BTW, the advantage of a cached version is not only on the reading side (I
mean, if there is any benefit for reading at all), but also when writing
to the database, since we write to the cache only, flushing it whenever
there are some spare CPU cycles. Though writing is certainly not that
performance critical anyway.

CU, Ingo

Other related posts: