Re: Thread cancellation and joining (GThreads)

[Robert Staudinger <robsta stereolyzer net>]

Philip,

Am Mon, den 09.08.2004 schrieb Philip Van Hoof um 9:12:
> Regretfully I didn't yet received an(y) answer to the problem :(
> 
> Does this mean that neither GThread thread-cancellation nor cancelling a
> ORBit-2 remote-call is possible and that I should move on with my
> live? :)

Michael Meeks explained how to get async/cancellable behavior by using
"oneway" calls:
http://mail.gnome.org/archives/orbit-list/2004-January/msg00040.html

HTH, 
Rob

> Perhaps if the GThread-subsystem can't be cancelled, the ORBit-2-folks
> could look at this issue? Perhaps by making it possible to make the
> CORBA calls non-blocking or something like that?
> 
> It sounds odd to me that a thread cannot get cancelled, but I have been
> reading some older mailinglist-threads about the issue. It looks like
> the GLib people have simply made the decision to not include thread-
> cancellation to GLib. Both for portability and other reasons. The other
> reasons for example being that the behaviour of functions like
> pthread_cancel is not always known.
> 
> Is that correct?
> 
> 
> 
> On Thu, 2004-08-05 at 14:15 +0200, Philip Van Hoof wrote:
> > 
> > Hi there,
> > 
> > 
> > I am building an application that does asynchrone calls with a CORBA
> > server. At both sides we are using ORBit. At the client-side the library
> > version is ORBit-2, at the server-side the library version is ORBit-1.
> > We managed to get that working already.
> > 
> > It's being asynchrone by using one thread that travels a queue that can
> > grow during the application-run. The queue-items have a priority-field
> > which is used to search the next most urgent call in the queue right
> > after the last job has finished.
> > 
> > This queue-mechanism is working. I am already doing multiple asynchrone
> > CORBA calls which will return for example image-data, which I use
> > between a gdk_threads_enter() and a gdk_threads_leave() to fill a
> > GtkDrawingArea with that image-data. This is ultra-stable and it just,
> > well ... works.
> > 
> > However...
> > 
> > We simulated a crash at the server-side (the CORBA-server). When the
> > CORBA-server crashes, the thread is waiting for the CORBA-server to
> > close the connection or .. well, it's waiting in the CORBA-function-
> > call. The result is that my queue stops processing (it actually waits)
> > until the server is brought completely down (killed) and/or restarted.
> > 
> > I don't want my queue-thread to wait in that call. If the CORBA-server
> > fails, I want to give my user the power to cancel the job. Even perhaps
> > to abort the whole queue-thread-execution and at a later time, restart
> > the queue-thread (or make it automatically restart and pick up where it
> > left).
> > 
> > However...
> > 
> > So far I failed to find a g_thread_cancel ()-like API call. I could use
> > some flag which would stop the thread at the first next call, and in
> > fact I am doing that to allow the queue-thread to shut-down properly and
> > to make my main-thread join it during the cleanup-phase of my
> > application (so while the application is shutting down). However, the
> > thread is not returning the CORBA-function that I am calling. It
> > actually hangs in that function ... I guess this is what they call a
> > blocking operation. Until completed, the function will not return. On
> > failure, it will only return when the server sends some failure-signal
> > or whatever. The server, which has crashed (simulated crash), will never
> > send that signal. Or perhaps the ORBit-library will abort on some
> > timeout, but I don't want my user to wait for such a timeout.
> > 
> > So basically, I want to forcefully abort the thread-execution.
> > 
> > Is that possible? Or is there a better method for my specific situation?
> > 
> > I have been thinking about launching a new thread per call. Since the
> > calls in the queue cannot be executed in parallel (by the server, this
> > is a fact which cannot be changed -the server is controlling a
> > mechanical device which just can't, really can't, do things in
> > parallel), I would have to make the queue-loop thread join the launched
> > thread and by that making it wait for termination in order to select the
> > next job to get launched. Which is fine for me (I could program it like
> > that). I just don't see a solution if I do it like that either, I will
> > face the exact same problem .. but will have yet another thread to
> > manage :) (but which I can perhaps forcefully kill more easily, of which
> > how to do that -> I don't know == my question).
> >  
> > Sidenote: When I do abort the thread, I want to have the opportunity to
> > cleanup allocated memory in that thread. Else aborting such a thread
> > would cause some memory to get leaked, I guess. So joining the thread
> > should still be possible, so when the thread does get cancelled, the
> > g_thread_exit ()-call should be used for that (else will the join fail,
> > I guess -when I kill the specific thread using a debugger, the join
> > hangs-).
> > 
> >