[interfacekit] Re: Registrar: towards design

>> system-hose is irreversible and you have to reboot.
>
>Hehe, very nice. :-P

Eh thanks, it took me 2 weeks  part time to figure out what
was going on =-)


.
>> >> [MIME database]
>> 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.

Hmm right.. my going through the OTracker source to stub
stuff out is a mix of pulling teeth and brain drain so
I've messed up my memories here.


> 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.
>
>> >there is some locking mechanism I haven't seen yet.
>> 
>> IMHO both reading and writing have to be synchronized....
.
>> 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.

Ah ok -- right, I seem to remember about that. Ignore my
pedantic stuff :-)   Maybe Be was relying on BNode::WriteAttr()
being an /atomic/ operation then.


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

Ok that's it, simple ops are very likely to be atomic operations;
(will have to involve Axel just to be sure he replicated this, maybe)
Didn't have comments to contribute on the rest of of the topics
so I'll stop here and watch the actual code writing...

cd (hoping to have time to contribute more than ~comments~ later!)

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