Re: Bluetooth and runloops in a dedicated thread.
Re: Bluetooth and runloops in a dedicated thread.
- Subject: Re: Bluetooth and runloops in a dedicated thread.
- From: David Giovannini <email@hidden>
- Date: Wed, 28 Apr 2010 07:28:09 -0500
On Apr 27, 2010, at 11:53 PM, Dave Keck wrote:
>> I knocked all the code down to the single UI thread and I rediscovered why I need multiple threads. My Obj-C objects give KVC semantics to the bluetooth device. A getter is waiting on a thread signal for the arrival of requested data. The requested data will never arrive since the single thread is in a blocked state. I also now have to turn the bluetooth scanner off to open a connection to a discovered device!
>
> I see. Note that if your getter method blocks until the Bluetooth
> operation is complete, your UI will also be blocked. So if the
> Bluetooth operation takes too long, you'll get the beachball.
The beach always happens because the thread to receive the bluetooth data can never receive the data under the single thread model. That is why I went multi-thread.
>
> Perhaps your getter could initiate the Bluetooth operation, and in the
> meantime return a cached object? If a cached object isn't available or
> you want to update the property's value, return a default value for
> the property, and initiate a "Loading..." spinner in the UI. Once the
> current state of the property is available, it updates the property
> which in turn updates the UI, and hides the loading spinner. For a
> snappy user experience, I'd try to avoid blocking in a getter method.
I cannot block at all. But sending a redundant KVC property broadcast on incoming data may work. I already have logic to not broadcast the change if there really was none.
So then all calls become synchronous. A property setter or getter becomes a request (cached value is returned in the current stack) and the real property change happens sometime in the future.
>
>> I don't see how to do the bluetooth communications in another process be non-trivial. Is there a simple approach to that?
>
> I implemented a simple custom protocol over Unix pipes, allowing the
> parent to direct the child in performing some simple Bluetooth
> operations. It certainly wasn't fun to implement, but from what you've
> said so far, I think handling the Bluetooth operations in the same
> process will work fine in your case if you structure it right.
Reading Apple's docs you linked pretty much says, "all our services only work in the main thread." That is a bit of a let down. The change in structure will be how you suggested - real results are not returned in the same call call stack.
There doesn't seem to be a way for the bluetooth scan and a bluetooth connection to work simultaneously. That is not a big deal, just forces the user into more of a modal workflow.
>
>> My next factoring will be to but the UI thread into a secondary thread, and let bluetooth own the main. Hopefully that will work.
>
> I hate the be the bearer of bad news, but UI code generally needs to
> remain on the main thread, too. See:
>
> http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html
Time to restructure the response mechanism...
Thank you,
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden