From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj80P-0003Ui-SU for qemu-devel@nongnu.org; Fri, 17 Apr 2015 11:16:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yj80M-0006nl-Lt for qemu-devel@nongnu.org; Fri, 17 Apr 2015 11:16:33 -0400 Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:38390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj80M-0006nh-El for qemu-devel@nongnu.org; Fri, 17 Apr 2015 11:16:30 -0400 Received: by wiun10 with SMTP id n10so24072501wiu.1 for ; Fri, 17 Apr 2015 08:16:29 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <553123CA.2090408@redhat.com> Date: Fri, 17 Apr 2015 17:16:26 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1429280557-8887-1-git-send-email-berrange@redhat.com> <1429280557-8887-26-git-send-email-berrange@redhat.com> In-Reply-To: <1429280557-8887-26-git-send-email-berrange@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v1 RFC 25/34] io: add QIOTask class for async operations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: Gerd Hoffmann , Stefan Hajnoczi On 17/04/2015 16:22, Daniel P. Berrange wrote: > A number of I/O operations need to be performed asynchronously > to avoid blocking the main loop. The caller of such APIs need > to provide a callback to be invoked on completion/error and > need access to the error, if any. The small QIOTask provides > a simple framework for dealing with such probes. The API > docs inline provide an outline of how this is to be used. > > In this series, the QIOTask class will be used for things like > the TLS handshake, the websockets handshake and TCP connect() > progress. Is this actually worth making it a heavyweight QOM object? In general if you don't do object_property_add_child (and I don't think here you do), it's simpler to just make it a C struct. In this case I even think you're leaking the task. You do object_ref twice (once at creation time, once before qio_channel_add_watch_full) and only have one object_unref. I would just do without reference counting, and add a qio_task_free() function that calls qio_task_finalize() and frees the QIOTask. BTW, do you have plans to use the GDestroyNotify argument to qio_task_new, or is it just for consistency? Paolo