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

[Jeremy Allison]

On Thu, Mar 23, 2017 at 07:16:18PM +0100, Ralph Böhme wrote:
> 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.

So cancel_smb2_aio() should just return 'false' ? Yeah ?

Until you put your cancellation code in - in which case
we can remove threads that haven't started yet...