Re: Questions about Run Loops
Re: Questions about Run Loops
- Subject: Re: Questions about Run Loops
- From: Joseph Kelly <email@hidden>
- Date: Wed, 16 Nov 2005 15:14:09 -0800
Oh would that Apple have developed a Bluetooth framework that was
thread-safe!
It is absolutely not advisable to use a dedicated worker thread to
call the Bluetooth api's. It's unreliable, and you won't even be able
to use IOBluetoothUI.framework.
But here are some hints:
I've developed a program model in which the main thread performs
Bluetooth operations at the behest of other threads which post
requests in a queue which the main thread reads. The api I present to
the client thread specifies that the operation be synchronous, thus
my request object contains a conditional mutex which blocks until the
main thread is done with the operation.
Instead of having the main thread busy poll the queue (the queue
itself is protected by a mutex), I set up a run loop source on the
main thread which is triggered by the client thread when it adds the
request object. The main thread wakes up, takes a request off the
queue, and performs the indicated operation using the async
Bluetooth apis whenever possible -- this lets the main thread handle
multiple requests at a given timeframe.
It got tricky when I tried to implement the requirement that the main
thread could also call the api and expect to block. The workaround is
to "pretend" to block, but not actually use the conditional mutex in
the request object. Instead, add the command to the queue which
triggers the source, and call CFRunLoopRun(), and in the completion
routine, which would normally set the "completed" condition on the
mutex, call CFRunLoopStop(CFRunLoopGetCurrent()).
Hopefully you won't have to support CFM applications, but if that's
the case, I've got more hints.
joe
On Nov 16, 2005, at 2:48 PM, Geoffrey Schmit wrote:
I'm creating a framework that handles interactions with a Bluetooth
device. While not too familiar with CFRunLoops, I've learned that
they are integral to Bluetooth on Mac OS X. For example, in order
for my RFCOMM event listener callback to be invoked, I need to
ensure that the run loop is running. My framework presents a
synchronous read method, so I handle this by invoking:
CFRunLoopRunInMode( kCFRunLoopDefaultMode, timeout, false );
in the read method. In my RFCOMM event listener callback, I exit
the run loop with:
CFRunLoopRef runLoopRef = CFRunLoopGetCurrent();
CFRunLoopStop( runLoopRef );
which returns control to the read method which then returns the data.
Is this a reasonable approach?
I've also read that all interactions with the Bluetooth frameworks
must be on the same thread. However, my framework is designed to
be multi-thread safe and to be called by the application with a
variety of threads. As expected, if the application invokes my
framework with a variety of threads, the above approach doesn't
work; the RFCOMM event listener callback is not invoked and the
CFRunLoopRunInMode function returns immediately and reports that
the run loop has no source or timers. If I restrict the
application such that it only calls my framework on the
applications UI thread, everything appears to work. However, this
has some undesirable side effects.
If I restrict the application to always calling my framework with
the same thread, but have that thread not be the same thread that
the application uses for UI, is this sufficient?
Alternatively, if I want to continue to allow the application to
invoke my framework with a variety of threads, can I create a
single thread in my framework that manages all Bluetooth
communication and then dispatch messages between this dedicated
thread and the application's threads? Can this dedicated thread be
a normal "naked" pthread?
Any advice would be appreciated.
Thanks!
geoff
--
Geoffrey Schmit
Senior Software Engineer
National Instruments
email@hidden
www.ni.com
_______________________________________________
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
_______________________________________________
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