Hi Arman, > I think the current way we have things is pretty simple and clean > already, but I'll go ahead with your suggestion if you guys prefer > that. > > One small question: is it safe to call io_destroy inside the > disconnect callback? If not, then we would have to post an > asynchronous task to clean up the IO and this would complicate the > code a little bit. We would actually still want to mark the the att > structure as invalid somehow so that any calls made to bt_att_send, > bt_att_register etc before the IO is freed can return false, which > would lead us to have a "bool invalid" field somewhere. > > In the timeout case, it might make sense to destroy the IO there. Then > again, we could leave it up to the upper layer to unref the bt_att > which would then destroy the connection. the struct io is an internal detail to bt_att. I do not follow the comment regards to upper layer. The input into bt_att_new will be a file descriptor. So what I thinking is that we just do io_destroy(att->io) and then att->io = NULL. Regards Marcel -- 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
