From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 6/6] tools/libxl: Fix datacopier POLLHUP handling to not always be fatal Date: Fri, 20 Feb 2015 14:05:16 +0000 Message-ID: <1424441116.30924.258.camel@citrix.com> References: <1424277263-27745-1-git-send-email-andrew.cooper3@citrix.com> <1424277263-27745-7-git-send-email-andrew.cooper3@citrix.com> <1424428981.30924.183.camel@citrix.com> <54E73CEF.8030407@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54E73CEF.8030407@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Wei Liu , Ian Jackson , Xen-devel List-Id: xen-devel@lists.xenproject.org On Fri, 2015-02-20 at 13:55 +0000, Andrew Cooper wrote: > > > > It's a bit of a shame that callers which don't care about specific > > pollhup handling have to provide two practically identical handlers. > > Up until this patch, all users either provided no POLLHUP handler, or > provided the same handler for both function pointers. Yes, and I'm saying it is a shame that those in the latter class now have to provide two callbacks instead of the one they used before. > > Is there any mileage in suggesting that the default callback type used > > for copyfail too might return a bool too in order that they can be > > shared? Even if it must always return True. > > > > Or perhaps some method to indicate that on pollhup, if pollhip callback > > is NULL, use the regular callback? (where some method might be the > > pollhup_callback==NULL itself?) > > Previously, every callback was issued after the datacopier had already > been killed. Now, the pollhup callback is called before the kill has > occurred, and is able to prevent the kill from happening. > > A different and far less invasive approach might be to have a per-fd > revent ignore mask. This would at least allow the callbacks to be made > when the datacopier is in a consistent state. Ian, any thoughts on this?