Threads problems
-
Well it works like this. First, I have a signal called
on_listView_customContextMenuRequested(const QPoint &pos)which will pop a context menu on right click. Then, based on what I select, I'll call the function that actually pops the menu,showContextMenu(pos). There, I assemble my menu with things like:myMenu.addAction("Unzip here")and other options. I guess it's worth to mention that I useQSignalMapperto connect some slots that have arguments (yes, I know it's deprecated, but I found that this way worked fine for me, might this actually be the issue? :/ ) and then connect everything like this:connect(action, SIGNAL(triggered(bool)), mapper, SLOT(map())); connect(mapper, SIGNAL(mapped(QString)), this, SLOT(unzip(QString))); mapper->setMapping(action, Fpath);And finally, in the
unzipslot I call theunzip_v2function. If there is the need of more explicit code, I'll post it, didn't want to make this reply too long. And also in theunzipslot is where I use thestd::async. -
What I think it's happening is that the
QStringargument that you pass tounzip_v2asconst char*goes out of scope beforeunzip_v2completed. could you show us the content ofunzip?P.S.
QSignalMapper is not the problem here. If you really want to get rid of it you can replaceconnect(action, SIGNAL(triggered(bool)), mapper, SLOT(map())); connect(mapper, SIGNAL(mapped(QString)), this, SLOT(unzip(QString))); mapper->setMapping(action, Fpath);with
connect(action,&QAction::triggered,this,std::bind(&MyClass::unzip,this,Fpath));(whereMyClassis the type of*this) -
Here is
unzip:void MainWindow::unzip(QString filePath) { boost::filesystem::path tempP(filePath.toStdString()); chdir(tempP.parent_path().string().c_str()); std::async(std::launch::async,&zipUtils::unzip_v2, tempP.filename().string().c_str()).get(); } -
What I think it's happening is that the
QStringargument that you pass tounzip_v2asconst char*goes out of scope beforeunzip_v2completed. could you show us the content ofunzip?P.S.
QSignalMapper is not the problem here. If you really want to get rid of it you can replaceconnect(action, SIGNAL(triggered(bool)), mapper, SLOT(map())); connect(mapper, SIGNAL(mapped(QString)), this, SLOT(unzip(QString))); mapper->setMapping(action, Fpath);with
connect(action,&QAction::triggered,this,std::bind(&MyClass::unzip,this,Fpath));(whereMyClassis the type of*this)Does this code even compile? is
zipUtilsa namespace?Try changing
std::async(std::launch::async,&zipUtils::unzip_v2, tempP.filename().string().c_str()).get();
tostd::async(std::launch::async,[](std::string nameString){zipUtils::unzip_v2(nameString.c_str());}, tempP.filename().string()); -
Yes, it does compile just fine and indeed,
zipUtilsis just a namespace. Even after changing those, it still continues to freeze. This problem seems to keep bugging me for a while now. -
Yes, it does compile just fine and indeed,
zipUtilsis just a namespace. Even after changing those, it still continues to freeze. This problem seems to keep bugging me for a while now.@DoubleC122 said in Threads problems:
it still continues to freeze.
Did you notice I'm not calling
get()at the end? that's the prime suspect for the freeze, did you remove it as well? -
I actually added it at the end since I noticed it wasn't there.
-
I actually added it at the end since I noticed it wasn't there.
-
I tested it right now once again but still won't unfreeze. I know that that
for(;;)inunzip_v2is quite heavy to compute with a large zip but that is why I thought it would get better with threads. -
I guess I found out a way to do this. It was just by chance, but, based on what you wrote here, I thought I'd try and use a lambda expression with QThread and QtConcurrent and to my surprise both worked, and I stuck with QThread in the end. The result looks like this:
QThread* thread = QThread::create([](std::string nameString){zipUtils::unzip_v2(nameString.c_str());}, tempP.filename().string()); thread->start();This won't freeze the gui anymore and performance is alright (although from time to time the system seems to struggle a bit, maybe it's something I can fix later). Anyway, thank you for your help, without this whole insight I would still be stuck :).