Hi, On Mon, Mar 12, 2012 at 7:42 AM, Jaganath <jaganath.k@xxxxxxxxxxx> wrote: > I have already sent a patch which wait for abort response before > disconnection. > Subject: [PATCH obexd] client: Fix ABORT command not sending when user > cancels the transfer. > Please review it and let me know your comments Afaik it didn't invalidate the transfer id thus the callback and user_data are still reachable so you might need to check again, also it should no longer be possible to cancel using the same id too. My proposal was actually to add g_obex_flush/g_obex_shutdown which can be used similarly to g_io_channel_shutdown, although for this specific problem it may not be the best solution due to stacks breaking if the transport is disconnected while responding, in case of SRM there maybe no response to wait and several packet are queued waiting POLL_OUT while the application wants to disconnect. Btw I don't think calling write_data will block since the io channel should be non-blocking so we could have the same behavior as g_io_channel_shutdown and return G_IO_STATUS_AGAIN if the packets could not be flushed. -- Luiz Augusto von Dentz -- 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
