[PATCH] Make server-side copy (copy-chunk) async

[Ralph Böhme]

On Thu, Mar 23, 2017 at 06:39:46PM +0100, Ralph Böhme wrote:
> On Thu, Mar 23, 2017 at 06:11:59AM -0700, Jeremy Allison wrote:
> > On Thu, Mar 23, 2017 at 10:39:24AM +0100, Stefan Metzmacher wrote:
> > > 
> > > The fact that the cancel function passed
> > > to tevent_req_set_cancel_fn() only gets the
> > > tevent_req *req pointer, makes it impossible to write a generic
> > > helper function on top of tevent.
> > 
> > So is it time for a tevent_req_set_cancel_fn_ex() that
> > allows a private pointer to be passed as well ?
> > 
> > Might that be a better/more general solution ?
> 
> That can already be done by putting the private pointer into the state of the
> request, so I don't see a real benefit here.
> 
> > 
> > > I think tevent_req_set_cancel_forwarding() is easy to use for
> > > all trivial cases where we do non parallel requests, which
> > > is the majority of all use cases.
> > > 
> > > If someone has a more complex situation, it's only solvable
> > > via a custom cancel function.
> > 
> > OK, it's just a little ugly IMHO. As I said, I
> > can live with it :-).
> 
> Thanks!
> 
> metze pointed out that the patch doesn't handle cancellation semantics
> correctly: from an MS-SMB2/MS-FSA/Windows behaviour perspective, cancellation
> means removing a pending request that is not yet in progress. As soon as a
> request in in-progress it must not be cancelled.

metze, I may be missing something, but from looking at cancel_smb2_aio() we make
the exact same mistake for async reads/writes that I was about to introduce for
async copy-chunk.

Ie cancel_smb2_aio() returns true, meaning operation was cancelled (implying it
was not yet runnig), but behaviour is to just detach it and leave it running. As
we can't currently cancel correctyy, I'd say we must not attempt to cancel
reads/writes with the current code.

Cheerio!
-slow