October 2005 - Bluetooth-dev

IOBluetoothUI thread safe?
by Joseph Kelly 07 Oct '05

07 Oct '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com joe _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… Background: To operate within my own specific requirements that I need to kick off a bunch of bluetooth operations from any thread (including the main thread) AND also operate within the IOBluetooth requirement that all operations be performed on a same thread, I've spawned a worker thread that handles all bluetooth operations (it gets awakened whenever there are commands placed in a queue and performs the bluetooth operations asynchronously, while the requesting threads are blocked until completion). So, is it safe or even advisable to call into IOBluetoothUI from this worker thread? My wish is to put up the standard bluetooth discovery dialog to let the user choose which device to connect to. The standard wisdom is never run UI from a non-main thread, but I might not have a choice? This email sent to site_archiver(a)lists.apple.com

1 0

Re: One more question...
by Joseph Kelly 05 Oct '05

05 Oct '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com I like Cocoa more and more. thanks, joe On Oct 5, 2005, at 3:38 PM, William Jon Shipley wrote: NSClassFromString() _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… Is there a fancy pants Cocoa-ish way of determining whether a particular objective-C class is present? I want to determine whether a given system has IOBluetoothDeviceInquiry w/o the crude "Gestalt Manager: am I running OS 10.4 or greater?" approach. This email sent to site_archiver(a)lists.apple.com

1 0

Re: One more question...
by William Jon Shipley 05 Oct '05

05 Oct '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com NSClassFromString() _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… Is there a fancy pants Cocoa-ish way of determining whether a particular objective-C class is present? I want to determine whether a given system has IOBluetoothDeviceInquiry w/o the crude "Gestalt Manager: am I running OS 10.4 or greater?" approach. This email sent to site_archiver(a)lists.apple.com

1 0

One more question...
by Joseph Kelly 05 Oct '05

05 Oct '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com joe _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… Is there a fancy pants Cocoa-ish way of determining whether a particular objective-C class is present? I want to determine whether a given system has IOBluetoothDeviceInquiry w/o the crude "Gestalt Manager: am I running OS 10.4 or greater?" approach. This email sent to site_archiver(a)lists.apple.com

1 0

Re: RFCOMM Channel Read/Write timeout strategy?
by Eric Brown 01 Oct '05

01 Oct '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com - Eric On Sep 30, 2005, at 5:19 PM, Joseph Kelly wrote: joe On Sep 29, 2005, at 5:20 PM, Marco Pontil wrote: ... Marco On Sep 29, 2005, at 5:07 PM, Joseph Kelly wrote: None so far. I'm just planning for the worst-case. joe This email sent to mpontil(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/esb%40apple.com This email sent to esb(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… All Bluetooth calls must occur from the same thread. It is not thread safe and there are many run loop event sources that get added by the framework that must all be on the same run loop. Fortunately all of the APIs have asynchronous versions. You really don't need multiple threads to do many things at once. Just issue an async call and go about your business. When the operation is complete, your callback (or delegate) will be called (assuming you're not blocking that run loop - which you likely won't be if you're using all async operations). If you really need multiple threads for other reasons, you're probably best off doing those other operations on a new thread and then signaling to the main thread when that work is done. The method -performSelectorOnMainThread:... is very useful for things like that although there are plenty of other mechanisms you can use as well. The other benefit of this design is that you'll never be blocking your main thread, so your UI is always available to the user. So what are my threading options again? IOBluetoothXXX works from any thread so long as its invoked from the same thread? Can inquiry be invoked from a different thread than device/channel operations? My requirement are thus: I need to perform the inquiry on a separate thread, but the connect/disconnect/read/write could be invoked synchronously from any arbitrary thread, most likely not the main thread. My thought is I will need a special monstro-bluetooth thread that does everything. Now wait, hold on. What happens if my thread is doing a pthread_cond_wait() (or NSConditionLock?) on a queue or something, and the channel gets some incoming data or NSTimer fires, then will the delegates ever get called? Because RFCOMM implements a flow control, there is the possibility that the other side does not empty its queue blocking the data send. So it is possible that data does not go over the air (and you do not get a notification for it). This is really an unlikely event, but if you think it can happen starting a NSTimer may be worth doing. If you issue an RFCOMM write call, the data will be delivered unless the connection is terminated. Unless there are horrible radio conditions, it seems unlikely to take very long before the write completes and you callback is called. Are you having specific problems with writes taking too long to complete? In answer to your question, your best bet is probably to create an NSTimer with the timeout that you want. Then in your callback, yoou can invalidate the timer if it hasn't fired. With that model, there is no need to block your main thread. Either the timer will fire, or you will get your write callback called. Thanks. I'm still deciding exactly how to arrange my code. I'm in a bind that I must design my bluetooth code to plug into a cross platform application that's expecting a particular interface and also be exported as a bundle that's loaded into a CFM application. _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/mpontil% 40apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: RFCOMM Channel Read/Write timeout strategy?
by Joseph Kelly 01 Oct '05

01 Oct '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: RFCOMM Channel Read/Write timeout strategy?
by Joseph Kelly 01 Oct '05

01 Oct '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com joe On Sep 29, 2005, at 5:20 PM, Marco Pontil wrote: ... Marco On Sep 29, 2005, at 5:07 PM, Joseph Kelly wrote: None so far. I'm just planning for the worst-case. joe This email sent to mpontil(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… So what are my threading options again? IOBluetoothXXX works from any thread so long as its invoked from the same thread? Can inquiry be invoked from a different thread than device/channel operations? My requirement are thus: I need to perform the inquiry on a separate thread, but the connect/disconnect/read/write could be invoked synchronously from any arbitrary thread, most likely not the main thread. My thought is I will need a special monstro-bluetooth thread that does everything. Now wait, hold on. What happens if my thread is doing a pthread_cond_wait() (or NSConditionLock?) on a queue or something, and the channel gets some incoming data or NSTimer fires, then will the delegates ever get called? Because RFCOMM implements a flow control, there is the possibility that the other side does not empty its queue blocking the data send. So it is possible that data does not go over the air (and you do not get a notification for it). This is really an unlikely event, but if you think it can happen starting a NSTimer may be worth doing. If you issue an RFCOMM write call, the data will be delivered unless the connection is terminated. Unless there are horrible radio conditions, it seems unlikely to take very long before the write completes and you callback is called. Are you having specific problems with writes taking too long to complete? In answer to your question, your best bet is probably to create an NSTimer with the timeout that you want. Then in your callback, yoou can invalidate the timer if it hasn't fired. With that model, there is no need to block your main thread. Either the timer will fire, or you will get your write callback called. Thanks. I'm still deciding exactly how to arrange my code. I'm in a bind that I must design my bluetooth code to plug into a cross platform application that's expecting a particular interface and also be exported as a bundle that's loaded into a CFM application. _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/mpontil% 40apple.com This email sent to site_archiver(a)lists.apple.com

1 0