Josselin Mouette wrote:|
Le lun 21/06/2004 à 00:34, Havoc Pennington a écrit :The patch does the reload in the signal handler - probably not good, especially in this case if you're installing a series of packages getting a second signal is not unlikely.Yes, that's what I thought. However gconfd is quite fast to reload its databases so it won't hassle the system (we have much more obnoxious stuff in packages postinsts, see e.g. update-mozilla-chrome). Of course I'd like to see it done a better way.
It is BAD idea doing this in the signal handler, it is well known behaviour that
running any non-reentrant code within signal handler can cause signicicant problem.
I can across this problem just this month in gconfd-2, See
Saying gconfd is quite fast, one talk about 100th mileseconds, but with a gigabytes
processer, even 10th mileseconds can have hundredthe signals events.
Sorry don't have a better suggestion at the moment, but certainly want to point up
the slippery slope :)
Needs to just write to a pipe or something to wake up the mainloop and do the reload there... I'm trying to think of a program with an example of this, dbus-daemon does it but that doesn't use GMainLoop.An example would be appreciated.As I see it, defaults and mandatory values as generated by gconftool in postinstall scripts are not configuration files which users should change, but system defaults.Why are packages changing defaults/mandatory though (outside of /schemas?) Factory defaults should be changed in packages by patching the .schemas file.I've already been told not to do that, but that's what Debian are usually doing. However, if the system administrator wants to change these defaults, he has to run gconftool again. Furthermore, the defaults are generated automatically by gconftool from the schemas, and this generation takes place in /etc, which is very bad. This has to go to /var/lib.If we have to make a change here I'd add a "schemas" source that's read before the "defaults" source, and leave "defaults" in /etcWhy should it be read before? Shouldn't defaults set by the system administrators be read before defaults introduced by the schemas?However I'm pretty concerned that by changing anything here we are making things even more confusing than they already are. The defaults/schemas mess is the single most confusing thing about gconf. http://log.ometer.com/2004-03.html#1 Of course changing this for Debian only or changing it in one way now and another way later will make the confusion worse. We should be sure we're going in the right direction.That's exactly why we are asking.That isn't the case I don't think. The admin default is /foo/bar. The schema default is stored in the schema object at /schemas/foo/bar. The package should not touch the admin default.But gconftool already creates %gconf.xml files in /etc/gconf/gconf.xml.defaults. Managing these files for both schema->default generation and administration is a nightmare. Regards,