From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4AlO-0002OY-2u for qemu-devel@nongnu.org; Sun, 04 Mar 2012 07:42:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4AlM-0007iV-9t for qemu-devel@nongnu.org; Sun, 04 Mar 2012 07:42:09 -0500 Received: from isrv.corpit.ru ([86.62.121.231]:60752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4AlM-0007i4-2e for qemu-devel@nongnu.org; Sun, 04 Mar 2012 07:42:08 -0500 Message-ID: <4F536316.5050503@msgid.tls.msk.ru> Date: Sun, 04 Mar 2012 16:41:58 +0400 From: Michael Tokarev MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] restart a coroutine? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel Since all block (bdrv) layer is now implemented using coroutines, I thought I'd give it a try. But immediately hit a question to which I don't know a good answer. Suppose we've some networking block device (like NBD) and want to be able to support reconnection - this is actually very useful feature, in order to be able to reboot/restart the NBD server without a need to restart all the clients. For this to work, we should have an ability to reconnect to the server and re-issue all requests which were waiting for reply. Traditionally, in asyncronous event-loop-based scheme, this is implemented as a queue of requests linked to the block driver state structure, and in case of reconnection we just walk over all requests and requeue these. But if the block driver is implemented as a set of coroutines (like nbd currently does), I see no sane/safe way to restart the requests. Setjmp/longjmp can be uses with extra care there, but with these it is extremly fragile. Any hints on how to do that? Thanks, /mjt