[SCM] Samba Shared Repository - branch master updated

[Jeremy Allison]

On Thu, Dec 18, 2014 at 02:31:17PM +0100, Volker Lendecke wrote:
> On Thu, Dec 18, 2014 at 08:21:04AM -0500, Poornima Gurusiddaiah wrote:
> > > That will remove the immediate concerns about pthread
> > > calls being used in the module, but still the
> > > calls to glfs_pread_async() are there, so the more sublte
> > > concern remains how the gluster gfapi library uses threads
> > > (and whether it can be avoided). I am currently looking
> > > into the code, trying to understand it, but I'm sure we
> > > will also get an update and information from Poornima,
> > > the patch author.
> > > 
> > Glusterfs is a multithreaded application. glfs_pread_async() doesn't really
> > create any more threads as compared to glfs_pread() api(which is the sync api).
> > By default when a connection to libgfapi is established (glfs_init()) there will
> > be 4 threads created, and will increase as the load increases. Out of four, we have
> > one queuing thread(which will grow) and one poller thread which receives the
> > acknowledgments from server.
> 
> Just to make sure: It's okay to fork() at any point while there are
> glusterfs threads doing their work, wherever they might be blocked? That
> would mean to properly mutex_lock all independent mutexes in the
> pthread_atfork prepare handler and unlocking those in the parent and
> child handlers, closing and possibly re-opening resources in the child?

100% correct. I'm betting that the glusterfs library might
need some fixes :-).