wxThread termination

[Ishtar]

Dear All,

I am in the process of developing an astronomical capture application for Linux. The application supports various specialist astronomical cameras, of which require a closed-source SDK provided by the manufacturer. Each camera has a specific thread (wxTread) which contains all the code associated with the relevant SDK. However, if one of these cameras goes offline the execution gets "stuck" in a closed-source function and never returns. This, of course, causes the thread to lock up.

I have developed a "heartbeat" function which constantly monitors the worker thread. If the thread stops sending a signal then the main thread knows something has gone wrong and so needs to kill the thread so it can be reinitialised. For obvious reasons I cannot use wxThead::Delete() and wxThread::Wait() because the thread has locked up. The only option I can see is to use wxTheead::Kill() but the documentation warns against this approach.

As I said above, I am using wxThread::Kill() followed by wxThread::Wait(). This works in the vast majority of cases but occasionally wxThread::Kill() does not kill the thread. Any ideas why Kill() doesn't always work? Furthermore, is there any other way that I can use to kill a thread cleanly if it has locked up?

Many thanks
Amanda

[ONEEYEMAN]

Hi, Amanda,
What type of threads do you use? Are they all joinable?

Thank you.

[evstevemd]

As you said, with wx you are left with Kill option only. But I see more design problem than wx issue. Your thread should monitor your camera and exist ::Entry once came goes offline. If it is a detached thread then it will delete itself. So wrap your camera code in TestDestroy and exist when it either evaluates to true or when camera goes offline. That way you will not have to worry about KILLing it!

[Ishtar]

But I see more design problem than wx issue. Your thread should monitor your camera and exist ::Entry once came goes offline. If it is a detached thread then it will delete itself. So wrap your camera code in TestDestroy and exist when it either evaluates to true or when camera goes offline. That way you will not have to worry about KILLing it!

Hi evstevemd & ONEEYEMAN

My threads, which are joinable, exit via TestDestroy() when everything is normal. However, when a camera goes offline, the execution gets stuck in the closed source function which is designed to grab a frame from the camera. When this happens, the closed source function never returns and so the execution of the thread can not reach TestDestroy(). I have no access to the source of this function and so have to deal with this issue another way. As I said in my original post, the only way I can see to deal with this is to kill the thread harshly.

The following code example shows roughly what I am currently doing: It's not precisely what I am doing but does serve as a working example.

Code: Select all

while(true)
{
	// Exit Thread
	if(TestDestroy())
	{       
		return (wxThread::ExitCode)exit_code;
	}
	
	// Get frame from camera - Get_Frame lives in another class where I use the manufacturer SDK to grab a frame
        // If we have a problem here, then the loop never iterates and so never reaches TestDestroy()
	CameraProcessor->Get_Frame();
}

However, evstevemd, are you suggesting that I should do something link this? I am not at home at the moment so cannot test this directly.

Code: Select all

while(true)
{
	// Exit Thread
	if(!TestDestroy())
	{
	         // Surely this will make absolutely no difference but would make the 
	         // code less readable. Does this really make a difference?
	        CameraProcessor->Get_Frame();
	}
	else {
	    return (wxThread::ExitCode)exit_code;
	}	
}

Many thanks
Amanda

[ONEEYEMAN]

Hi, Amanda,
If the thread/driver/software is stuck in the infinite loop ot means that there is a bug somewhere.
Did you check if the new version of this camera software exist? Did you talk to that dev team? Did you file a bug?

This is their issue and it needs to be fixed on their side. If you workaround works - great. But maybe the real problem lies with the camera software?

Thank you.

[Ishtar]

Dear ONEEYEMAN,

I absolutely agree, unfortunately, this specific manufacturer is not very forthcoming. I guess I am stuck, at least for now, with wxThread::Kill() and then clean up in the destructor instead of OnExit().

Many Thanks
Amanda

[evstevemd]

Hi Amanda,

Dear ONEEYEMAN,

I absolutely agree, unfortunately, this specific manufacturer is not very forthcoming. I guess I am stuck, at least for now, with wxThread::Kill() and then clean up in the destructor instead of OnExit().

Many Thanks
Amanda

Sorry for late reply.
Your code is exactly what I was saying so it is right. Until SDK get corrected you are left only with that alternative.