new aio engine

Volker Lendecke Volker.Lendecke at SerNet.DE
Thu Jul 19 04:36:42 MDT 2012

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


SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen, mailto:kontakt at

More information about the samba-technical mailing list