site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=TjlngNtYMAjl7QgcLyDvtedEyUeFsk4dnfmEHptVmnk=; b=uCu4Awtg3ANUlGi5IJJERdZYRJhmW3DqOU8Krg3n595URgP2W6Cf9FKFQwCZn5wrSW hfYECrXjgPXz8P/EzNZ/o2S6jMT9/ILNWZv1XCtrGwLPBK9qlm6+AlY47cqbEZwBU91h dVAoUPb8uF9lwem3FfKj3FC48IPSHl7FwoWAA= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Udpt/pugptmW0o20gadpTLX9J8N9nY4Fx5ZZ7SRlFw5jod/qEw+s88B5VKCzzjaoIc yp0eksO2aGT6ORo5ntQ5Eq1/sVMtBS3XbtdiwwtEWFuW1RekAfXSf7dAAOOXwi73EGkl TclBm0wzmylf5SYGEtstyi7A50+rZ1+o9yly8=
I can easily share a single thread between all bluetooth devices. That will solve any multi-threading issues in the bluetooth services. Bluetooth installs itself as an NSRunLoop source, somehow. IOBluetoothValidateHardware used to do that, and the NSRunLoop had kept on running.
I recommend against using the Bluetooth APIs anywhere but the main thread. There's been some past discussion on this list regarding thread-safety and IOBluetooth, and it seems the Apple guys suggest confining Bluetooth calls to the main thread, too. See: http://lists.apple.com/archives/bluetooth-dev/2007/Sep/msg00003.html http://lists.apple.com/archives/bluetooth-dev/2009/Sep/msg00003.html With that said, much of the IOBluetooth APIs are asynchronous, allowing you to specify a delegate to be notified when a particular operation is complete. Are you sure you need the Bluetooth calls to exist in their own thread? If so, spawn a helper process and put the Bluetooth calls there. This is what I do in my own projects - it works fine.
I cannot have the BlueTooth library pick a runloop at random. Depending on configuration, this application may have a UI and/or may have a web-service. Bluetooth communications needs to be sandboxed into a designated RunLoop.
I'm not sure how a UI/web service/Bluetooth combination makes it necessary that the Bluetooth calls exist in their own thread; as mentioned, many of the Bluetooth APIs are non-blocking. If I were writing this sort of combination program, I would either: 1. put the UI/Bluetooth stuff in the main thread, and the web service stuff in a separate thread, or 2. put the UI stuff in the main thread, Bluetooth stuff in a separate helper process, and the web service stuff in a separate thread.
How do I tell the Bluetooth library to install itself as a source on a specific runloop of a specific thread? If I need to start that thread in main, I'll do it!
Based on the links above, "make sure you do ALL Bluetooth related activities on the first thread from which you call anything in the Bluetooth stack." I think Jason would agree though, that that advice is error-prone and should only be considered a last resort. That advice was also given 2.5 years ago. _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com