Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Trusted Contributor
Posts: 160
Registered: ‎09-13-2012
My Device: 9900
My Carrier: vodafone

Weird behavior with bool

Hi all,

 

I have suffered this problem for days now and just got round it by doing while(!exit_application) rather than while(connected) in one of my threads which relies on the main process setting connected to true. It never evaluates to true even though i set it before actually starting the other thread. 

 

I currently just have the connected variable declared in my .h file. I have pthread_mutex_lock/pthread_mutex_unlock wrapped around every call to the connected variable but it doesn't help. I have also set connected as volatile.

 

What are the issues to look out for that could cause this to happen which i haven't already mentioned?

 

Regards

 

C

Developer
Posts: 1,041
Registered: ‎07-16-2008
My Device: ಠ_ಠ

Re: Weird behavior with bool

I don't understand the difference between you're two whiles. They're both bools yes? Can you show some code? (Setting it and start the thread / accessing it from your thread / how its declared in the h file)

Trusted Contributor
Posts: 160
Registered: ‎09-13-2012
My Device: 9900
My Carrier: vodafone

Re: Weird behavior with bool

[ Edited ]

thanks for taking the time mreed, I will just tell one thing that might help and then ill sort /paste my code , some of the functions are declared in .h and some are declared in .cpp. The keyboard_thread function for example I just cannot get past the compiler if I try to declare the function in .h rather .cpp. When I set the connected variable to true this is done in a .h declared function. Difference also being that the calling function has MyWindow::someFunction and the thread function doesn't. Just to give you an idea of my problem when I change the thread function declaration to .h file instead..

 

pthread_create(&keyboardthread, 0, keyboard_thread, NULL);

pthread_create(&keyboardthread, 0, &keyboard_thread, NULL);

pthread_create(&keyboardthread, 0, *keyboard_thread, NULL);

pthread_create(&keyboardthread, 0, (void*)keyboard_thread, NULL);

 

None will run.

 

 

one of the erros i get..

 

Multiple markers at this line
- ISO C++ forbids taking the address of an unqualified or parenthesized non-static member function to form a pointer to member function. Say
'&std2::MyWindow::keyboard_thread'
- cannot convert 'void* (std2::MyWindow::*)(void*)' to 'void* (*)(void*)' for argument '3' to 'int pthread_create(pthread_t*, const pthread_attr_t*, void* (*)(void*),
void*)'

 

 

 

** also I have tried pthread_create(&keyboardthread, 0, &::keyboard_thread, NULL); as that was how it being done in libffbb.

 

Trusted Contributor
Posts: 160
Registered: ‎09-13-2012
My Device: 9900
My Carrier: vodafone

Re: Weird behavior with bool

[ Edited ]

some code how it is now but the compiler fails..

 

void MyWindow::createKeyboardThread()
{
if(keyboardthread == NULL)
pthread_create(&keyboardthread, 0, &::keyboard_thread, NULL);
}

void* MyWindow::keyboard_thread(void* arg)
{
	///bool connected2 = reinterpret_cast<bool*>(&arg);
	bps_initialize();
	screen_request_events(externalscreencontext);
	navigator_request_events(0);
	pthread_mutex_lock(&mutex);
	while (connected) {
		pthread_mutex_unlock(&mutex);
		/* Handle user input */
		handle_events();
		pthread_mutex_lock(&mutex);
	}
	keyboardthread = NULL;


}

 

Trusted Contributor
Posts: 160
Registered: ‎09-13-2012
My Device: 9900
My Carrier: vodafone

Re: Weird behavior with bool

I'm thinking I'm asking a stupid question by no response but..

 

I need to have some functions (qt slots) declared in MyWindow.cpp otherwise qt slots wouldn't work so when i try to have thread function also declared in MyWindow.cpp to match I can't get past compiler (see above posts), if i have it declared in MyWindow.h then it compiles but when I set connected variable in slot to true the variable isn't changed in the thread.

 

Please can someone at least tell me whats stupid about the question/problem!

 

Thank you.

Developer
Posts: 1,041
Registered: ‎07-16-2008
My Device: ಠ_ಠ

Re: Weird behavior with bool

[ Edited ]

You can't pass in a class function in to your pthread method, or at least I have never been able to. It has to be a global function, however you can pass in the instance of your class as the argument/cookie. Where you have NULL you would pass in the instance. Then from your global function, call your classes function. If the class function is private, you can mark the global function as a friend.

 

Check out encoding_thread:

https://github.com/hardisonbrewing/libffbb/blob/master/public/ffbbenc.h

Trusted Contributor
Posts: 160
Registered: ‎09-13-2012
My Device: 9900
My Carrier: vodafone

Re: Weird behavior with bool

I have been trying to implement what you suggest mreed and still the same weird behaviour persists. In 3 simple functions the connected variable (now an int like exit_application) gets set to 1, a thread is started and the thread reads the same variable and it is 0 as it was when initialised and set.

 

I will paste some code in case I am doing what you suggest wrong.

 

void MyWindow::createKeyboardThread()
{
	
		pthread_create(&keyboardthread, 0, &testfunction, this);
}

void* testfunction(void* arg)
{
	reinterpret_cast<MyWindow*>(&arg)->keyboard_thread(&arg);
}

 

void* MyWindow::keyboard_thread(void* arg)
{
	///bool connected2 = reinterpret_cast<bool*>(&arg);
	bps_initialize();
	screen_request_events(externalscreencontext);
	navigator_request_events(0);
	//pthread_mutex_lock(&mutex);
	while (connected) {
		//pthread_mutex_unlock(&mutex);
		/* Handle user input */
		handle_events();
		//pthread_mutex_lock(&mutex);
	}
	keyboardthread = NULL;


}

 

BlackBerry Development Advisor
Posts: 683
Registered: ‎11-29-2011
My Device: PRIV
My Carrier: Rogers

Re: Weird behavior with bool

Just looks like some simple C++ misuse.


cjonesy wrote:

 

void MyWindow::createKeyboardThread()
{
	
		pthread_create(&keyboardthread, 0, &testfunction, this);
}

void* testfunction(void* arg)
{
	reinterpret_cast<MyWindow*>(&arg)->keyboard_thread(&arg);
}

 in testfunction(), you've passed in a "this" pointer as arg.  then you went and referenced it with &arg later?  don't do that.  Just cast "arg", not &arg.  Second, you're trying to call keyboard_thread with the same arg?  why would you pass "this" into keyboard_thread?  I ask because below, you are then trying to cast that arg as a bool later (or rather you're casting a pointer to that arg (&arg) as a bool... actually, I just noticed you commented it out:

 

void* MyWindow::keyboard_thread(void* arg)
{
	///bool connected2 = reinterpret_cast<bool*>(&arg);
}

 


I believe I do similar stuff in HelloCamera with static functions as callbacks, etc. if you wanted to use that as reference.  In any event, here is the approximate skeleton of what you want:

 

class foo {  // incomplete class, but you get the idea
    static void* threadFunc(void* arg);  // STATIC!
    void createThread();
    void someOtherFunction();
    void stopTheThread();
    bool run;
    ptherad_t tid;
};

void* foo::threadFunc(void* arg) {
    foo* inst = (foo*)arg;  // have to find our "this" instance
    while (inst->run) { 
        // please don't run-ready in here!!
        // (eg. sleep, yield, or block appropriately)
        inst->someOtherFunction();
    }
    return NULL;
}

void foo::someOtherFunction() { // whatever your thread does }

void foo::createThread() {
    run = true;
pthread_create(&tid, 0, &threadFunc, (void*)this); } void foo::stopTheThread() { run = false; // may also use pthread_cancel() if your thread needs to be unblocked, etc.
pthread_join(tid, NULL); }


add your own mutexes, etc.  in general, simply checking a bool exit condition is generally good enough, but only if it's a bool check!  (eg. checking for non-zero.  if you are checking for a specific int value, then you definitely need a mutex).

 

Also note.. the advantage of using a static member function is that it has full access to all non-public class members, unlike a standalone function would.  A standalone function can only access public members.

 

Cheers,

Sean

 

 

 

Trusted Contributor
Posts: 160
Registered: ‎09-13-2012
My Device: 9900
My Carrier: vodafone

Re: Weird behavior with bool

Cheers for the reply Sean,

 

After a few more hours on this I finally understand what im doing wrong (I think!) - I thought I could trust connected variable in threads because the other thread (network thread) was working ok with it but really I have just found a line of code which sets it to true if it connects in network thread itself. If I do this with keyboard thread (set it true right before loop) it doesn't fall through either (quite obvious) but when I set connected to false in a disconnect button then all threads seems to register the false being set, (weird that connected being set to true isn't picked up though when that is also from a qt slot).

 

Looking at your skeleton code and the more understanding im gaining I'm realising I would have done a lot of stuff differently and still might have to!

 

Thanks again.

 

C

 

 

 

 

Trusted Contributor
Posts: 160
Registered: ‎09-13-2012
My Device: 9900
My Carrier: vodafone

Re: Weird behavior with bool

Just to clarify the weird behaviour was caused by setting the variable to true in the slot function and then thinking this was ok/set.

 

When I implemented Seans skeleton code and checked using while(mw->connected) the same happened - connected evaluated to false, however I hadn't set connected = true in the createThread() function - just in the slot.  When I set connected to true in createThread()  and not just the slot - it all works fine.

 

Thanks again mreed and Sean.