Re: [fuse-devel] question about threading

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi Michael,

I believe std::thread is just another front end for the standard pthread 
library functions. On my RHEL 7 system version 2.17 of the pthread library 
is installed (part of the 2.17 glibc package). On my SLES 12 system 
version 2.19 is installed and debugging my test program works fine. On 
Fedora 26 the glibc version is 2.25.

Thanks for making me aware on this.

Regards

Martin Petermann         Saeumerstrasse 4 
CSU      Rueschlikon, 8803
Phone:  +41-44 724 86 95         Switzerland
e-mail:         ma...@zu... 

Michael Theall <pig...@gm...> wrote on 07/08/2017 17:50:07:

> From: Michael Theall <pig...@gm...>
> To: Martin Petermann <ZR...@ch...>, Nikolaus Rath 
<Nik...@ra...>
> Cc: fus...@li...
> Date: 07/08/2017 17:50
> Subject: Re: [fuse-devel] question about threading
> 
> Hi Martin,
> 
> I did try this, but on Fedora 26. I could not reproduce the issue. 
> It's possible that a newer version of gcc implements std::thread 
> differently or a newer version of gdb precludes the problem you are 
> experiencing. I might try building the latest gcc and compiling your
> example with that to see if it makes a difference.
> 
> On the other hand, I am suspicious of your use of the system() call 
> after putting fuse_loop_mt() in another thread. I'm not sure what we
> expect to happen when your process forks after calling fuse_mount().
> In my filesystem I implemented my own daemonization (instead of 
> using fuse_daemonize()), but I don't remember what problem it solved.
> 
> Regards,
> Michael Theall
> 
> On Mon, Aug 7, 2017 at 10:05 AM Martin Petermann <ZR...@ch...> 
wrote:
> Hi Nikolaus,
> 
> thanks for looking at this. Not my preferred solution but probably will
> execute the fuse call backs within a separate process.
> 
> Regards
> 
> Martin Petermann         Saeumerstrasse 4
> CSU      Rueschlikon, 8803
> Phone:  +41-44 724 86 95         Switzerland
> e-mail:         ma...@zu...
> 
> 
> 
> Nikolaus Rath <Nik...@ra...> wrote on 07/08/2017 16:14:02:
> 
> > From: Nikolaus Rath <Nik...@ra...>
> > To: fus...@li...
> > Date: 07/08/2017 16:15
> > Subject: Re: [fuse-devel] question about threading
> >
> > On Aug 07 2017, "Martin Petermann" <ZR...@ch...> wrote:
> > > sorry for sending my previous mail in html format. As you requested 
I
> > > changed to the latest libfuse code in git:
> > >
> > > commit 4be90a6f9a9f242b1f480024a7cb3c749fcf5390
> > > Author: Nikolaus Rath <Nik...@ra...>
> > > Date:   Sun Aug 6 13:24:40 2017 +0200
> > >
> > >     Released 3.1.1
> > >
> > > The behavior seems to be the same like before.
> > >
> > > I had to update the test code to the following (hello3.cc):
> > [...]
> > >
> > > I compiled it in the following way:
> > >
> > > g++ -std=c++11 -g2 -ggdb -fPIC -Wall -Werror -D_FILE_OFFSET_BITS=64
> > > -lpthread /usr/local/lib/libfuse3.so -o hello3 hello3.cc
> > >
> > > Without debugging it seems to work fine:
> > [..]
> > >
> > > When debugging the code it hangs like in the following output:
> > >
> >
> > Same here. Interestingly enough, it also happens when attempting to 
run
> > under Valgrind.
> >
> > My guess is that the problem is actually with the debugger itself. It
> > most likely does not expect that a system call like open() or read()
> > would block until the debugged program makes progress in another
> > thread. In your particular case, the debugger probably takes a lock 
when
> > starting a new thread (which makes sense, because it has to setup the
> > corresponding monitoring structures), but the lock is currently held 
by
> > the thread that executes open() or read(). This is awfully complicated
> > to debug, because the debugger only makes forward progress when you
> > abort the FUSE connection and the syscall returns - so your backtrace 
is
> > generated when the problem has actually disappeared.
> >
> > The only way to verify this is to actually debug the gdb process that
> > debugs the filesystem process. I don't know if that's possible, but I
> > would expect it to show that gdb itself is blocking on a mutex.
> >
> > This may sound far fetched, but actually had this very problem with
> > Python when writing testcases. Unfortunately there is no way to fix it
> > other than not having the filesystem process accessing its own
> > mountpoint.
> >
> >
> > But as I said in the beginning, this is only a guess. If there is any
> > way you could factor your application into two processes, that would 
be
> > the easiest solution.
> >
> > Best,
> > -Nikolaus
> >
> > --
> > GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
> >
> >              »Time flies like an arrow, fruit flies like a Banana.«
> >
> >
> 
------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > --
> > fuse-devel mailing list
> > To unsubscribe or subscribe, visit https://lists.sourceforge.net/
> > lists/listinfo/fuse-devel
> 
> 
> 
> 
------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> --
> fuse-devel mailing list
> To unsubscribe or subscribe, visit https://lists.sourceforge.net/
> lists/listinfo/fuse-devel