Hi Arman, >> 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. >> > > What I meant was that, upon receiving the timeout callback, should > whoever created the bt_att be responsible for explicitly destroying > the connection by calling bt_att_unref (which will internally free the > struct io)? Just thinking out loud. the bt_att should stay around. It is just the internal io that should be destroyed. Since the bt_att is reference counted and comes in from higher layers we should not touch. Meaning you will end up with a bt_att where io == NULL in case the transport disconnects or times out. > >> So what I thinking is that we just do io_destroy(att->io) and then att->io = NULL. >> > > In the disconnect case, is this safe to do from directly inside the > disconnect callback given to io_set_disconnect_handler? Most likely not at the moment. We might want to make it safe if it is not. 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
