[openbeosstorage] Re: Registrar-Based Notification Mechanism

> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> [...]
> [...]
> > The additional memcpy() I was referring to, has the following 
> > origin: 
> > Without a notification mechanism for the kernel, the entity at 
> > which 
> > the event occurred would have `allocated' ring buffer memory and 
> > written the notification data directly into it, while with the hook 
> > approach, it first has to write everything in a structure (on the 
> > stack 
> > certainly) passed to the hooks, and then it is memcpy()d into the 
> > ring 
> > buffer. Not that a memcpy() is extraordinarily expensive. ;-)
> 
> Why is that=3F 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=3F

That may depend on the implementation. Assuming that you have a 
notification_event 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.

> [...]
> > > BMessage::Flatten() yourself and using write=3D5Fport() manually=
> > > 3D3F 
> > > It 
> > > should 
> > > be possible to get the target port for the Registrar, right=3D3F
> > The problem is not the target port (i.e. looper), but the handler. 
> > This 
> > info is stored in the BMessage and must be set for each target it 
> > shall 
> > be delivered to. It should, of course, be possible to find out, 
> > where 
> > the info resides in the flattened message and set it each time, but 
> > I 
> > would prefer, if the BMessage implementation provided sending 
> > flattened 
> > messages to a given target.
> 
> 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 
_set_message_target_(). 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_t BMessage::SendFlattened(const 
void *data, size_t size, BMessenger target,...)' that sets the target 
in the flattened data and sends it to the respective port.

CU, Ingo

Other related posts: