Question

I am writing an application in Qt to be deployed on Symbian S60 platform. Unfortunately, it needs to have Bluetooth functionality – nothing really advanced, just simple RFCOMM client socket and device discovery. To be exact, the application is expected to work on two platforms – Windows PC and aforementioned S60.

Of course, since Qt lacks Bluetooth support, it has to be coded in native API – Winsock2 on Windows and Symbian C++ on S60 – I’m coding a simple abstraction layer. And I have some problems with the discovery part on Symbian.

The discovery call in the abstraction layer should work synchronously – it blocks until the end of the discovery and returns all the devices as a QList. I don’t have the exact code right now, but I had something like that:

RHostResolver resolver;
TInquirySockAddr addr;
// OMITTED: resolver and addr initialization

TRequestStatus err;
TNameEntry entry;
resolver.GetByAddress(addr, entry, err);
while (true) {
    User::WaitForRequest(err);
    if (err == KErrHostResNoMoreResults) {
       break;
    } else if (err != KErrNone) {
        // OMITTED: error handling routine, not very important right now
    }

    // OMITTED: entry processing, adding to result QList

    resolver.Next(entry, err);
}
resolver.Close();

Yes, I know that User::WaitForRequest is evil, that coding Symbian-like, I should use active objects, and so on. But it’s just not what I need. I need a simple, synchronous way of doing device discovery.

And the code above does work. There’s one quirk, however – I’d like to have a timeout during the discovery. That is, I want the discovery to take no more than, say, 15 seconds – parametrized in a function call. I tried to do something like this:

RTimer timer;
TRequestStatus timerStatus;
timer.CreateLocal();

RHostResolver resolver;
TInquirySockAddr addr;
// OMITTED: resolver and addr initialization

TRequestStatus err;
TNameEntry entry;

timer.After(timerStatus, timeout*1000000);

resolver.GetByAddress(addr, entry, err);
while (true) {
    User::WaitForRequest(err, timerStatus);

    if (timerStatus != KRequestPending) { // timeout
        resolver.Cancel();
        User::WaitForRequest(err);
        break;
    }

    if (err == KErrHostResNoMoreResults) {
        timer.Cancel();
        User::WaitForRequest(timerStatus);
        break;
    } else if (err != KErrNone) {
        // OMITTED: error handling routine, not very important right now
    }

    // OMITTED: entry processing, adding to result QList

    resolver.Next(entry, err);
}
timer.Close();
resolver.Close();

And this code kinda works. Even more, the way it works is functionally correct – the timeout works, the devices discovered so far are returned, and if the discovery ends earlier, then it exits without waiting for the timer. The problem is – it leaves a stray thread in the program. That means, when I exit my app, its process is still loaded in background, doing nothing. And I’m not the type of programmer who would be satisfied with a “fix” like making the “exit” button kill the process instead of exiting gracefully. Leaving a stray thread seems a too serious resource leak.

Is there any way to solve this? I don’t mind rewriting everything from scratch, even using totally different APIs (as long as we’re talking about native Symbian APIs), I just want it to work. I’ve read a bit about active objects, but it doesn’t seem like what I need, since I just need this to work synchronously… In the case of bigger changes, I would appreciate more detailed explanations, since I’m new to Symbian C++, and I don’t really need to master it – this little Bluetooth module is probably everything I’ll need to write in it in foreseeable future.

Thanks in advance for any help! 🙂

Answer 1

The code you have looks ok to me. You’ve missed the usual pitfall of not consuming all the requests that you’ve issued. Assuming that you also cancel the timer and do a User::WaitForRequest(timerStatus) inside you’re error handing condition, it should work.

I’m guessing that what you’re worrying about is that there’s no way for your main thread to request that this thread exit. You can do this roughly as follows:

• Pass a pointer to a TRequestStatus into the thread when it is created by your main thread. Call this exitStatus.
• When you do the User::WaitForRequest, also wait on exitStatus.
• The main thread will do a bluetoothThread.RequestComplete(exitStatus, KErrCancel) when it wants the subthread to exit, where bluetoothThread is the RThread object that the main thread created.
• in the subthread, when exitStatus is signalled, exit the loop to terminate the thread. You need to make sure you cancel and consume the timer and bluetooth requests.
• the main thread should do a bluetoothThread.Logon and wait for the signal to wait for the bluetooth thread to exit.

There will likely be some more subtleties to deal correctly with all the error cases and so on.

I hope I’m not barking up the wrong tree altogether here…