FreeLists / openbeosstorage / [openbeosstorage] Re: Registrar-Based Notification Mechanism

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
[...]
> > Why is that=3D3F Why should the hook approach make it necessary to 
> > prepare 
> > the data that has to be written to the ring buffer while the 
> > "direct" 
> > approach wouldn't=3D3F
> That may depend on the implementation. Assuming that you have a 
> notification=5Fevent structure, that shall contain the relevant data in 
> a 
> flattened form, and the hook functions of the subscribers shall be 
> called with a pointer to such a structure, then, obviously the data 
> need to be copied into that structure before the hooks can be called. 
> Unless, and that is maybe what you are referring to, the structure 
> does 
> already exist anyway and thus doesn't need to be composed for that 
> purpose -- then there is no extra overhead.
> 
> But if you have to fill in such a structure -- you do perhaps 
> allocate 
> it on the stack -- then this structure has to be copied into the ring 
> buffer by the hook responsible for the registrar communication in a 
> second step. While, otherwise, without the kernel hooks, the function 
> would allocate space in the ring buffer and fill in the data 
> directly.

Ah yes, now I understand what you meant, thanks!

[...]
> > Ah, yes, I see, so it should provide a Flatten() call that already 
> > defines the target handler - something it has to provide internally 
> > anyway. That should be very easy to do.
> No, that's not what one would want. Setting the target of a BMessage 
> (fTarget, fPreferred) can easily be done now using the friend 
> function 
> =5Fset=5Fmessage=5Ftarget=5F(). The point is to flatten the message only once 
> and for each target set the respective handler in the flattened data. 
> I 
> could imagine a private `static status=5Ft 
> BMessage::SendFlattened(const 
> void *data, size=5Ft size, BMessenger target,...)' that sets the target 
> in the flattened data and sends it to the respective port.

Again, you thought more than me... :-))
Sure, that's exactly what one would want to have, but that again, would 
be easy to do, once BMessage is in place. Just a friend method that 
sets the target and calculates the checksum to complete the flattened 
buffer - that can be used by Flatten(), too (but only once, there).

Adios...
   Axel.