Elektrified X.org released (was: X configuration paradigm, and a proposal)

[Avi Alkalay]

On Sun, 5 Dec 2004 20:00:59 -0500, Avery Pennarun <apenwarr at nit.ca> wrote:
> On Sun, Dec 05, 2004 at 04:17:36PM -0300, Avi Alkalay wrote:
> 
> > Yeah I know.... I'll try to stick in the high level, but I'm worried
> > about dependencies. It makes no sense to have /lib/libkdb.so depending
> > on libs under /usr/lib.
> >
> > The 5 minutes I spent reading about inotify made me believe it is a
> > kernel module, but I couldn't find it, nor the /dev entry, nor the
> > dmesg messages in the FC2 machine I have close to me right now. Is
> > this stuff already included in regular distros kernels ?
> 
> Remember, all that matters right now is that the *API* of elektra be
> compatible with any kind of smart notification mechanism.  That definitely
> means you should be compatible with gamin, but make sure plain inotify and
> FAM would work too... and don't forget about your plain polling, which is
> actually a fine solution for certain kinds of daemons and a small number of
> keys.
> 
> The actual polling implementation can be swapped out later, as I found out
> when I wrote my UniConf backend.  The only problem is that the current API
> *requires* polling, which isn't going to work well with programs using, say,
> libevent.
> 
> My advice continues to be that you should support simple callback
> registrations: call this function when this keyset changes.  Don't call this
> function anymore when this keyset changes.  Poll for changes now and call
> any registered events.  (And be aware that the "poll" function might not
> *actually* be necessary in some implementations.)

Any suggestion on how to implement this in a libc-like library ?
Callbacks imply in having a paralel execution, outside the main
program, waiting for an event, or polling. A.K.A threads, forks,
daemons, or event loops. Am I right ?
Its not clear for me if signals and alarms can help here....




> Note: you also should look at recursive notifications.  I have lots of
> programs that want to watch, for example, /system/users/*/password and be
> told whenever anyone's password changes, so they can reconfigure
> /etc/rsync.secrets or something.  The current system doesn't seem to lend
> itself well to that at all.
> 
> Avery



So lets talk the function prototype language here.
Would you guys write me please some C prototypes of key change
monitoring (or notification) functions that you think will be usefull,
and preferably compatible with a libc type of library (Elektra....) ?

Currently Elektra has this:

u_int32_t kdbMonitorKeys (KeySet *interests,
          u_int32_t diffMask,
          unsigned long iterations,
          unsigned sleep)

u_int32_t kdbMonitorKey (Key *interest,
          u_int32_t diffMask,
          unsigned long iterations, 
          unsigned sleep)

If you pass zero to the iterations parameters, you'll block forever
until some change happens. If you wanna cancel this situation,
something outside that context must kill the blocked process or
thread. This is why this is low level, that fits in a smart program
(that wants to manage threads), or encapsulated into a higher level
framework (GConf or UniConf).

Thoughts?

Maybe we should have this conversation out from xdg, and in the Elektra list....

Thank you,
Avi