new aio engine

Jeremy Allison jra at
Thu Jul 19 10:16:11 MDT 2012

On Thu, Jul 19, 2012 at 12:36:42PM +0200, Volker Lendecke wrote:
> On Thu, Jul 19, 2012 at 09:39:17AM +0200, Stefan (metze) Metzmacher wrote:
> > It's really good to see this finally in master.
> > 
> > > It has one (at the moment fatal) flaw: If a file is closed
> > > while async requests are still on the fly, the pread/pwrite
> > > might end up on the wrong file. Two ways out: Hold back the
> > > close SMB until all async requests are finished, or put the
> > > os-level fd on the pending close queue until all the async
> > > requests are finished. I tend to implement the latter.
> > 
> > I think we should implement asys_cancel() more correct,
> > which requires a pthreadpool_job_cancel(), which might use
> > pthread_cancel(). I think that would fix this problem
> > and it would also be possible to return the correct status
> > to the smb level read and write.
> I'm not sure I want to use pthread_cancel. All I have read
> about it tells me this is nasty stuff that you want to avoid
> if possible at all. Reading man pthread_cancel() means that
> we can end up with blocking behaviour for asys_cancel.
> Cancellation is done asynchronously according to the
> manpage. So you fire off the cancel request, but you are not
> sure when exactly this is executed. If the cancelled thread
> is somewhere on its way in the kernel and does not see the
> cancellation request in time, and we then do the close/open
> in another thread, I'm not sure we don't have the same race
> again. This means that when we do a cancel, we have to make
> sure it went through with a pthread_join. But this means
> that if we are trying to cancel a job really stuck in
> kernel, we will get stuck as well.
> Maybe I'm over-paranoid, but pthread_cancel to me looks
> scary.


Please let's not start using pthread_cancel. That thing
really scares me. It affects a great deal of code under
the covers. Plus on Linux+glibc it's implemented with
realtime signals.

It's much, much easier to set an internal flag that
a request was canceled and deal with it when the
operation returns.


More information about the samba-technical mailing list