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.

One response to “g_thread_cancel”

  1. Anonymous

    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.

Bad Behavior has blocked 2769 access attempts in the last 7 days.