[openbeosstorage] Re: Registrar-Based Notification Mechanism
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 12 Feb 2003 00:56:50 -0800
[SNIP-SNIP-SNIP]
> 1) Subscription/unsubscription for notifications: This is a bit ugly,
> since the functions for that live in libroot and the primary target
> for
> the request is the registrar. Either the request is passed through a
> port
> directly to the registrar, or it travels into the kernel and goes the
> same
> way the to the registrar the notifications take (i.e. through the
> shared
> memory). Once there, the listener is added to the appropriate
> list/hashtable/...
Since, as you mentioned elsewhere, sub/unsub requests are not
particularly time sensitive, I think I prefer the latter suggested
method (syscall into kernel then back out through the ring buffer). I
guess the port method could avoid requiring changes to the kernel to
add sub/unsub for a new set of notifications, but you'll need to make
changes anyway to actually implement said notifications, so you
wouldn't really be gaining anything.
[MORE SNIP]
> Mmh, that's it, I think. At least my mind feels a bit emptier now. ;-)
That all sounds very reasonable and well-thought-out from where I'm
standing. Any thoughts from kerneland? I hadn't thought about it much
before, but I really like the idea of having a common notification
system like this.
-Tyler
Other related posts:
