[interfacekit] Re: Registrar: towards design


[PulseBug]

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

Hehe, very nice. :-P

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

Yep, as well as B_INFINITE_TIMEOUT-1 and some negative times.

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

There are really no watching options at all. The Tracker can't make 
that much mistakes. It just receives the 100 notification messages and 
perhaps fetches some additional data for each one. Perhaps it's worth 
to have a thorough look at the code.

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

You really don't need to convince me. ;-)
I'd personally prefer to let the registrar be the only one with access 
to the database at all. But as I wrote earlier I played a bit with the 
debugger (reading assembler dumps isn't my favorite subject ;-) and 
found out that the simple BMimeType::Get*() methods do directly read 
the database. And if I haven't missed anything, there is no locking 
mechanism for this case.

Nevertheless I don't think anything as bad as in your examples can 
happen when reading the database directly, or, to be precise, when 
reading exactly one attribute of one file directly. Currently you 
always have to write a whole attribute at once and I suspect that the 
data are cached on a higher than the FS level. And I'm pretty certain 
that the FS implements a locking mechanism to prevent reading an 
attribute while writing to it at the same time. Thus I would consider 
writing/reading an attribute atomar operations and hence no locking is 
needed.
Note: I'm only talking about those BMimeType::Get*() methods that deal 
with one-attribute-data, e.g. GetAttrInfo(), GetFileExtensions(), 
GetIcon(),...
For complex ones like GetSupportingApps() the registrar is contacted.

CU, Ingo

Other related posts: