Re: g-thread-cancel
Richard, I'd really like to answer you, and this is the second time I'd like to do that, but unfortunatly you do not allow comments on your blog.
Well, before my karma reaches unknown depths let's add some real content to this posting:
I don't really know, why that function is missing, but my guess it, that randomly killing threads is quite dangerous, as threads share the process with your program. Stopping the thread at some random point most certainly will leave your entire program in an inconsistent state.
So common suggestion for stopping threads, is adding explicit cancelation points to your thread. Something like the following.
volatile gboolean running = TRUE;
static void* my_thread (void *data)
{
while (running) do_work ();
}
void stop_thread (GThread *thread)
{
running = FALSE;
g_thread_join (thread);
}
Disclaimer: Don't take that code too verbatim. I absolutly hate threads and try to avoiding them when possible.
Btw, thanks to the genius fork() syscall, processes are dead cheap on *nix platforms. They are much more secure than threads. Specially if you think you have to interrupt them them.
Using the technique of pull-the-answer-out-of-bugzilla for the second time today, I present you
http://bugzilla.gnome.org/show_bug.cg...
The problem with different process is the communication between processes. Shared Memory, messages, pipes, etc. are really boring when we have use them.
I prefer thread because it is easier to deal with. But I agree with you about the signals.
As far as I can recall, using thread cancelation is a pain in the ass when it comes to portability. There are only a few platforms which correctly implement pthread_cancel, and most implementations have quirks or are totally b0rked. Last time I read something about this topic, at least MacOS X, Solaris and NetBSD had totally defective implementations -- or no implementation at all! Just spit out “pthread_cancel problems” at some random search engine and you will find a lot of information.
One can always invert program logic and join threads instead of cancelling them as suggested. I believe this is the reasong why the Glib developers decided not to include a thread cancellation primitive...
I can only recommend to run a glib event loop in every stream. It provides the necessary hooks for locking and waking up main loops that run in different contexts.
s/stream/thread
Sorry - spammers like me too much - I was getting 50+ spams a day from livejournal. Thanks for your answer, I'll work out how I can use this in PackageKit.