2010/10/24 Elvis Pfützenreuter <epx@xxxxxxxxxxx>: > Hello, > >> In that case, the problem is in the remote side, because the Bluetooth >> SIG certification requires the devices to support reconnections, so >> the problem is not in our side but in the remote side that isn't >> compliant with the standard. I think we don't have to change our >> implementation regarding buggy devices that don't follow the >> specification correctly. > > I think an HDP device is NOT required to support reconnections. In HDP spec item 5.2.11 there is that bitmap in SDP record that says whether device supports reconnections and CSP. Sorry, you are right about that, reconnections are not mantadory in all cases for sources. May be we should check this flags before keeping the state and emitting the signal. > >> More over, the situation that you mention. When receiving a >> ChannelDeletion, the application shouldn't close the data channel, >> because the in the normal situation, the DBus object for the data >> channel will be removed, so no closing of the channel will be >> performed, the only thing that should happen is that the application >> will "forget" about this channel. When the second ChannelConnected is >> received, the application will typically perform an acquire that, in >> this case, will be very simple because the channel will be already >> connected and the fd will be transmitted. > > So the application must follow a very specific behaviour when handling a ChannelDeleted signal, and worse yet, it must do it to fix a problem that we could fix simply by changing the way channel paths are named. > The only thing that the application should do when receiving a ChannelDeleted signal is to forget about this channel because the Channel object does not exists any more and no more calls to the channel API could be done. Nevertheless if you close the fd get from the Acquire petition, nothing will happen to the new channel, because the new channel has a new btiochannel. I have to experiment with this to be completely sure and see how DBus fd-passing deals with this, but everything points that nothing will happen when closing the previous get fd. > If it was the case that we simply could not change the channel path naming, this behaviour should at least written very clearly in API. > >> In general, I think, guys, that we are thinking again in very estrange >> situations. As we said in the Recife's meeting we should design the >> implementation and the API for working with compliants devices, not >> with buggy ones and also we have to simplify the use for the API, >> making it simple for the application programmers in the most usual >> cases not in the strange ones, that will happen very rarely. > > It's weekend, and playing devil's advocate is fun :P > > Seriously now, my objective is the same, avoiding that a perfectly sensible application act (closing fd after receiving a ChannelDeleted event) causing a race condition. And IMHO a condition that may happen with compliant devices as well. Let's see what fd-passing is managing the fd and decide having this data. Tomorrow I'll experiment with this and reply to the list with the results. Regards. Jose -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
