[interfacekit] Re: Registrar: towards design


On 2002-06-17 at 04:42:13 [-0700], interfacekit@xxxxxxxxxxxxx wrote:
> 
> 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.
[...]
> 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.

Excellent. :-)

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

Fair enough :-)

-Tyler

Other related posts: