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

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

"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
[...]
> > > 2) Ports: The event notifications are written to a port. This 
> > > doesn't work very well with passive entities, I suspect.
> > They could, of course, spawn a thread for that purpose.
> That makes them a little less passive, doesn't it=3F ;-)

A little less, yes, but since that thread only waits until something 
happens, it's not that active anyway.

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

[...]
> Yep. Actually for a moment I had the even scarier idea, to provide 
> the 
> facilities to add arbitrary notification services, that can for 
> instance be provided by modules. Then one could subscribe to a 
> service, 
> one doesn't even know about. But that does also mean, that one 
> doesn't 
> know the parameters needed by the service or the structure of the 
> notification. I suspect when trying to turn that into something 
> useful, 
> one would end up with a whole component concept and had invented Java 
> Beans for the kernel. ;-)

Most probably :-))
We should have well defined targets when we try to implement something 
:-)

> > For whatever reason - I have never understood that call. It's not 
> > really usable from C anyway. I could only use it to check if the 
> > BeOS 
> > kernel would send BMessages directly ;-)
> Its existence allowed us to already completely implement BQuery. So 
> I'm 
> not exactly ungrateful that it exists. ;-)

Okay, that would be one reason :-)

[...]
> > Despite the slow progress (Erik!!!), what's preventing calling 
> [I think, Erik is not this list, so... ;-)]

Damnit :-)

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

[...]
> > > I haven't thought much about that yet. Above is a spontaneous
> > > brain-storming -- maybe some more concrete ideas will form when 
> > > thinking a bit more about it.
> > Well, I think it's already the best idea for that problem, but 
> > please 
> > go on, have a better one again ;-P
> I didn't promise anything, did I=3F ;-)

Granted :-)

Adios...
   Axel.