StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POSymbian C++ - synchronous Bluetooth discovery with timeout using RHostResolver
text
Body
copied!<p>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.</p> <p>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.</p> <p>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 <code>QList</code>. I don't have the exact code right now, but I had something like that:</p> <pre><code>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(); </code></pre> <p>Yes, I know that <code>User::WaitForRequest</code> is <em>evil</em>, 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.</p> <p>And the code above <em>does</em> 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:</p> <pre><code>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(); </code></pre> <p>And this code <em>kinda</em> works. Even more, the way it works is <em>functionally</em> 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.</p> <p>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.</p> <p>Thanks in advance for any help! :)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload