> I noticed that the /usr/libexec/gam_server process is *not* killed
> upon exit from my (KDE) graphical session.
the server exits after 30 seconds without client connection.
> I will compile glib with
> --disable-mem-pools --enable-gc-friendly
> in the next few days with KDE-3.3.2.
Not needed, 0.0.19 has it's own copy of the GLib list code
> pristine and KDE
Not my business, I don't use it, my point is reproductability
of report. I learnt for example that depending on the automake
version something as simple as gamin 0.0.18 get compiled completely
differently. Pristine mean that the bug report is valid of others
using the distro.
> did you consider using the C++ STL to replace glib in gamin
the client side does *NOT* use glib. The client side of FAM
was using C++ STL forcing all client to load the library :-(
that's one of the reasons we rewrote the package altogether.
The server side is a standalone program, based on glib because
- we know glib well
- I don't want to code in C++
> I noticed that the /usr/libexec/ gam_server process is *not* killed
> upon exit from my (KDE) graphical session.
the server exits after 30 seconds without client connection.
> I will compile glib with gc-friendly
> --disable-mem-pools --enable-
> in the next few days with KDE-3.3.2.
Not needed, 0.0.19 has it's own copy of the GLib list code
> pristine and KDE
Not my business, I don't use it, my point is reproductability
of report. I learnt for example that depending on the automake
version something as simple as gamin 0.0.18 get compiled completely
differently. Pristine mean that the bug report is valid of others
using the distro.
> did you consider using the C++ STL to replace glib in gamin
the client side does *NOT* use glib. The client side of FAM
was using C++ STL forcing all client to load the library :-(
that's one of the reasons we rewrote the package altogether.
The server side is a standalone program, based on glib because
- we know glib well
- I don't want to code in C++
Daniel