Hmm. PackageKit development has hit another snag. When we use a spawned backend that needs cancelling we just send the new process a SIGQUIT and then SIGKILL after a small delay. Other backends are compiled and thus use threads.

It appears that g_thread_cancel doesn't exist in GLIB. I've found one hacky implimentation here, but that didn't look particulally safe. Is there a good reasons the pthread internal stuff can't be nicely wrapped up in a nice glib call?

I guess I have to use something like select to poll, although I'm a bit of a newbiew with l33t UNIX stuff like this. This also seems a really
broken way to work around missing functionality. Advice and code snippits welcome.

Published by


Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

One thought on “g_thread_cancel”

  1. I think the bottom line is that you can't safely cancel threads in C/POSIX unless they were written to push cleanup handlers: http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/term_threads.htm And yeah, no one does that. Using separate processes isn't a panacea either; sending SIGKILL to a backend is just as unsafe if it wasn't written to expect to be killed. For example, if it uses files as database locks. Doing so won't happen to crash the main packagekit process, but the system is still hosed. Bottom line is each backend will have to be evaluated for cancelability, and will probably need to be canceled in a backend-specific way.

Comments are closed.