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

[Avery Pennarun]

On Sat, Dec 04, 2004 at 08:41:37PM -0200, Avi Alkalay wrote:

> On the other hand, Elektra is very low level, in the same level as
> libc functions. If it was notification instead of monitoring, how it
> will notify a program that doesn't have an event loop? One way I can
> think is to install a callback and Elektra will create a new thread or
> process to wait for changes (remember we aren't in an event loop
> context) and call your callback function, but it will work inside a
> different thread and it can cause problems to your logic. So the
> solution I was able to think is to give you the basics (monitoring),
> and based on your program logic, you'll or wait for a change, or wrap
> it in a thread context that your program can handle. The way
> monitoring is implemented in Elektra is the best I could think for its
> descentralized nature.

I gathered from looking at the API that the monitor won't notice changes if
you just call it occasionally; if the changes happen while the monitor
function isn't running, they'll be missed.  Hopefully I'm wrong about this,
because if it's true, then your monitor function will never be useful to
anyone.  I'll assume I just misread the code :)

Assuming you can just call the monitor function occasionally to *check* for
changes, then the next part of the trick is doing the monitoring somewhere
other than in main().  For example, it needs to be called from a glib
mainloop.  This should be pretty easy if you just set up a timer object to
run your monitor code occasionally... but then you have the problem that
every part of your program which wants to monitor keys will have to set up
its own timer, which is inconvenient.

The way to fix this is for elektra to maintain a list of callback functions
on keys.  The central monitor function, which gets run from your mainloop
"somehow" (ie. using a timer), calls these callback functions when it
notices a change.  Then alternative Elektra storage backends, such as my
UniConf backend, could implement the callback registration mechanism in a
way that *doesn't* require waiting for the monitor function, so the monitor
function can just be empty rather than polling inefficiently.

Have fun,

Avery