I am using a QWebFrame to visualize some data and I use evalueateJavascript method to update data on Javascript. Here is my function to do this.
QWebFrame * webFrame;
void setValue(int idx, double value){
webPage->page()->mainFrame()->evaluateJavaScript(QString("setDataValue(%1,%2)").arg(QString::number(idx)).arg(QString::number(value)));
}
In QT application I can call this function via a button call back as many time without causing an error.
I want to call this setValue function from a separate thread to visualize incoming data. When I call setValue function from a separate thread, after few or first iteration application crash. I tried with both QThread and boost threads, but results are same.
void dummyTest(){
for(int i = 0; i < 1000; i++)
setValue(0,rand() % 150);
}
This dummyTest function is also working without problems when called via a button callback, but crash on running on a separate thread.
Here is the code for thread initialization
void startSerialProcessing() {
boost::thread_attributes attr;
attr.set_stack_size(1024);
std::cout << "dummy processor started. \n";
serialThread= new boost::thread(&MavLinkAL::dummyTest, this);
}
My observation is this crash only happens when setValue is called from a separate thread. Here is important lines from coredump file viewed from gdb.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f3f0d6f361f in WTF::StringImpl::~StringImpl() ()
from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
#1 0x00007f3f0d6583f8 in JSC::JSValue::toStringSlowCase(JSC::ExecState*) const
() from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
#2 0x00007f3f0d68a396 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
#3 0x00007f3f0d55a9f1 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
#4 0x00007f3f0d56313f in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
Any help to solve this problem is really appreciated. Thanks.
QWebFrame functions are neither reentrant nor thread safe. They can only be invoked from main GUI thread. Qt allows you to deliver a message to another thread quite easily. Make setValue function a slot, and connect it to a signal emitted from the processing thread.
EDIT: As Vladimir Bershov suggested in the comment below, one can also use QMetaObject::invokeMethod() with Qt::QueuedConnection to achieve the same result.
Related
I'm creating a networked game in Unity using tcp based sockets.
(I'm new to networking and threading stuff).
I'm using System.Net.Sockets async methods like socket.BeginReceive() and socket.EndReceive().
All the client-server connecting and messaging works. But as soon as I try access anything from a Monobehavior (so that I can actually have any effect on the Unity game), like a gameobject's transform, an exception is thrown telling me that I can only access these properties from the main thread.
My question is: why am I not back on the main thread in the callback to foo.beginRecieve(), or at least after I call foo.EndReceive()? How do I return to the main thread using the async socket api? Will I end up having to use the synchronous socket api and just handle the threading myself so I can properly resync with Unity's main thread?
Thanks!
Any help would be much appreciated.
//code which sets up the callbacks which are executed when a client receives a message from the server
void BeginReceive() => _clientSocket.BeginReceive(_messageReceivedBuffer, 0, _messageReceivedBuffer.Length, SocketFlags.None, ReceiveCallback, null);
void ReceiveCallback(IAsyncResult result)
{
_clientSocket.EndReceive(result);
var msg = _serializer.ByteArrayToObject<NetworkMessage>(_messageReceivedBuffer);
//this clientmanipulation manipulates the game grid and the gameobjects' which it references
//it's in this method that an exception gets thrown and the code breaks
msg.ClientManipulation(_gameGrid);
BeginReceive();
}
In general for EndReceive:
Before calling BeginReceive, you need to create a callback method that implements the AsyncCallback delegate. This callback method executes in a separate thread and is called by the system after BeginReceive returns. The callback method must accept the IAsyncResult returned by the BeginReceive method as a parameter.
[...]
The EndReceive method will block until data is available.
Usually you would use a pattern often referred to as Main Thread Dispatcher using a ConcurrentQueue. For Unity this is quite easy since you already have something that is surely always been executed in the main thread: Update
public class Example : MonoBehaviour
{
...
private ConcurrentQueue<Action> _mainThreadActions = new ConcurrentQueue<Action>();
private void Update()
{
// Handle all callbacks in main thread
while(_mainthreadActions.Count > 0 && _mainThreadActions.TryDequeue(out var action))
{
action?.Invoke();
}
}
void BeginReceive()
{
_clientSocket.BeginReceive(_messageReceivedBuffer, 0, _messageReceivedBuffer.Length, SocketFlags.None, ReceiveCallback, null);
}
void ReceiveCallback(IAsyncResult result)
{
_clientSocket.EndReceive(result);
var msg = _serializer.ByteArrayToObject<NetworkMessage>(_messageReceivedBuffer);
// On threads / possibly async code enqueue the action to be invoked in the main thread
_mainThreadActions.Enqueue(()=> {msg.ClientManipulation(_gameGrid)});
BeginReceive();
}
}
This question is about GTK and threads.
You may find it useful if your application crashes, freezes or you want to have a multithreaded GTK application.
Main Loop
In order to understand GTK you must understand 2 concepts.
All contemporary GUIs are single-threaded. They have a thread which processes events from window system (like button, mouse events).
Such a thread is called main event loop or main loop.
GTK is also single threaded and not MT-safe. This means, that you must not call any GTK functions from other threads, as it will lead to undefined behaviour.
As Gtk documentation states,
Like all GUI toolkits, GTK+ uses an event-driven programming model. When the user is doing nothing, GTK+ sits in the “main loop” and waits for input. If the user performs some action - say, a mouse click - then the main loop “wakes up” and delivers an event to GTK+. GTK+ forwards the event to one or more widgets.
Gtk is event-based and asynchronous. It reacts to button clicks not in the exact moment of clicking, but a bit later.
It can be very roughly written like this (don't try this at home):
static list *pollable;
int main_loop (void)
{
while (run)
{
lock_mutex()
event_list = poll (pollable); // check whether there are some events to react to
unlock_mutex()
dispatch (event_list); // react to events.
}
}
void schedule (gpointer function)
{
lock_mutex()
add_to_list (pollable, something);
unlock_mutex()
}
I want a delayed action in my app
For example, hide a tooltip in several seconds or change button text.
Assuming your application is single-threaded, if you call sleep() it will be executed in main loop.
sleep() means, that this particular thread will be suspended for specified amount of seconds. No work will be done.
And if this thread is main thread, GTK will not be able to redraw or react to user interactions. The application freezes.
What you should do is schedule function call. It can be done with g_timeout_add or g_idle_add
In the first case our poll() from snippet above will return this event in several seconds. In the latter case it will be returned when there are no events of higher priority.
static int count;
gboolean change_label (gpointer data)
{
GtkButton *button = data;
gchar *text = g_strdup_printf ("%i seconds left", --count);
if (count == 0)
return G_SOURCE_REMOVE;
return G_SOURCE_CONTINUE;
}
void button_clicked (GtkButton *button)
{
gtk_button_set_label (button, "clicked");
count = 5;
g_timeout_add (1 * G_TIME_SPAN_SECOND, change_label, button);
}
Returning a value from function is very important. If you don't do it, the behaviour is undefined, your task may be called again or removed.
I have a long-running task
Long-running tasks aren't different from calling sleep. While one thread is busy with that task, it can't perform any other tasks, obviously. If that is a GUI thread, it can't redraw interface. That's why you should move all long-running tasks to other threads. There is an exception, though: non-blocking IO, but it's out of topic of my answer.
I have additional threads and my app crashes
As already mentioned, GTK is not MT-safe. You must not call Gtk functions from other threads.
You must schedule execution. g_timeout_add and g_idle_add are MT-safe, unlike other GTK functions.
That callbacks will be executed in main loop. If you have some shared resources between callback and thread you must read/write them atomically or use a mutex.
static int data;
static GMutex mutex;
gboolean change_label (gpointer data)
{
GtkButton *button = data;
int value;
gchar *text;
// retrieve data
g_mutex_lock (&mutex);
value = data;
g_mutex_unlock (&mutex);
// update widget
text = g_strdup_printf ("Current data value: %i", value);
return G_SOURCE_REMOVE;
}
gpointer thread_func (gpointer data)
{
GtkButton *button = data;
while (TRUE)
{
sleep (rand_time);
g_mutex_lock (&mutex);
++data;
g_mutex_unlock (&mutex);
g_idle_add (change_label, button);
}
}
Make sure mutexes are held as little as possible. Imagine you lock a mutex in another thread and do some IO. The main loop will be stuck until the mutex is released. There is g_mutex_try_lock() that returns immidiately, but it can bring additional syncronization problems because you can't guarantee that the mutex will be unlocked when mainloop tries to lock it.
Follow up: but python is single-threaded and GIL et cetera?
You can imagine that python is multi-threaded application run on a single-core machine.
You never know when the threads will be switched. You call a GTK function but you don't know in which state the main loop is. Maybe it free'd resources just a moment before. Always schedule.
What is not discussed and further reading
Detailed documentation on glib main loop can be found here
GSource as a more low-level primitive.
GTask
I am trying to write a module for nodeJS which wraps libspotify. The goal is to write a webapp that allows the remote control of a device playing music from spotify.
I have decided to go along the spshell example to ensure thread safety and write a "Spotify Service" in plain C that starts a seperate thread which calls all the API functions.
The nodeJS module then just calls a few provided functions to interact with spotify. The code for the service can be found here: http://pastebin.com/KB6uwSC8 The new thread gets started at the bottom.
Now, if i call this in a simple program like this (the fget is just to have a simple way for the login to complete). I used c++ to get as close to as node-gyp compiles the code.
#include <stdio.h>
extern "C" {
#include "objects/SpotifyService.h"
}
int main(int argc, char** argv) {
login();
char string[100];
fgets(string, 100, stdin);
fprintf(stdout, "Got: %s", string);
logout();
fgets(string, 100, stdin);
fprintf(stdout, "Got: %s", string);
return 0;
}
It works fine. I can't get this to crash.
If I use the same exact "Service" in nodeJS (meaning I just call login() and logout() and do nothing else), it crashes sometimes when logging out, like 7-8/10 times. I've tried lots of stuff, including:
Copying the compiler flags from node-gyp to my small example
fiddling with the thread attributes of the spotify thread
compiling on OSX and Debian
using libuv instead of plain pthreads
compiling my "service" to a shared library and call this from node
to no avail. It just crashes. It seems to crash less when called from within gdb, but that could be random.
A stack trace from gdb shows the following:
Thread 3 (Thread 0x7ffff65fd700 (LWP 21838)):
#0 0x00007ffff678f746 in ?? () from /usr/local/lib/libspotify.so.12
#1 0x00007ffff6702289 in ?? () from /usr/local/lib/libspotify.so.12
#2 0x00007ffff6702535 in ?? () from /usr/local/lib/libspotify.so.12
#3 0x00007ffff6703b5a in ?? () from /usr/local/lib/libspotify.so.12
#4 0x00007ffff6703c86 in ?? () from /usr/local/lib/libspotify.so.12
#5 0x00007ffff66c5c8b in ?? () from /usr/local/lib/libspotify.so.12
#6 0x00007ffff679a5b3 in sp_session_process_events () from /usr/local/lib/libspotify.so.12
#7 0x00007ffff6aa7839 in spotifyLoop (nervNicht=<value optimized out>) at ../src/SpotifyService.c:103
#8 0x00007ffff70118ca in start_thread () from /lib/libpthread.so.0
#9 0x00007ffff6d78b6d in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()
(In OSX gdb showed that the function called in libspotify is called "process_title".)
Since nothing has helped so far i just don't have any idea if i can get this to work or if it is something in libspotify that's just incompatible with nodeJS. I don't understand how node-gyp links the .o files, maybe there something goes wrong?
I found two other projects on github that try to do this, but one of them puts the spotify main loop actually in Javascript and the other one uses node 0.1.100 and libspotify 0.0.4 and hasn't been updated in 2 years. I couldn't learn anything from both of them.
OK, i've played around some more. I just ignored the logout error and continued to implement other features.
I added a new sp_playlist_container creation in the logged_in callback and apparently that helped. After that, the node module does not crash anymore (or hasn't yet).
static sp_playlistcontainer_callbacks pc_callbacks = {
.container_loaded = &rootPlaylistContainerLoaded,
};
static void rootPlaylistContainerLoaded(sp_playlistcontainer* pc, void* userdata) {
int numPlaylists = sp_playlistcontainer_num_playlists(pc);
fprintf(stdout, "Root playlist synchronized, number of Playlists: %d\n", numPlaylists);
}
static void loggedIn(sp_session* session, sp_error error) {
if(SP_ERROR_OK != error) {
fprintf(stderr, "Error logging in: %s\n", sp_error_message(error));
} else {
fprintf(stdout, "Service is logged in!\n");
}
//This is absolutely necessary here, otherwise following callbacks can crash.
sp_playlistcontainer *pc = sp_session_playlistcontainer(spotifySession);
sp_playlistcontainer_add_callbacks(pc, &pc_callbacks, NULL);
}
But the sp_playlist_container creation must be in the logged_in callback, if i called it in another function (say, "getPlaylistNames") the program crashed, too.
I'll see if it continues to work and hope this answer can help others.
Currently I have some troubles passing a QVector between to threads. At the moment I have a main thread (GUI-Thread) and an worker thread that emits frequently QVector arrays. Directly before emitting the data inside the vector looks good. The receiver is a slot in the main thread but the Data received in by the slot is garbled.
Here are some parts of my code:
Emit in the worker thread:
void Pipeline::process
{
QVector<float> buffer(w * h * d);
// filling the vector with RGB-Values
emit this->pushBuffer(buffer, w, h, d);
}
Connection of signal and slot in the main thread:
QObject::connect(this->_pipeline.data(), SIGNAL(pushBuffer(const QVector<float>, int, int, int)), this->ui->widgetFiltered, SLOT(setBuffer(const QVector<float>,int,int,int)));
Slot in the main thread:
void GLWidget::setBuffer(const QVector<float> buffer, int dataSizeX, int dataSizeY, int dataSizeZ)
{
// at this point the contents inside 'buffer' is garbled
}
The Thread is started by using QObject's moveToThread and QVector<float> registered to the meta-system by qRegisterMetaType< QVector<float> >("QVector<float>"); in the main method.
Is it possible that the data gets lost after Pipeline::process returns? I am not sure how the implicit sharing inside QVectorbehaves in this multi-threaded case.
Any help would be appreciated.
Greetings
Wolf
a) Register metatype QVector. Add this line before app.exec() in your main function:
qRegisterMetaType<QVector<float> >("QVector<float>");
Without this QueuedConnection won't work.
b) explicitly say that your signal and slot connected via Qt::QueuedConnection
if you do moveToThread after connect, this should fix slot execution in proper thread.
I am learning about threading and multithreading..so i just created a small application in which i will update
the progressbar and a static text using threading.I vl get two inputs from the user, start and end values
for how long the loop should rotate.I have 2threads in my application.
Thread1- to update the progressbar(according to the loop) the static text which will show the count(loop count).
Thread2 - to update the another static text which will just diplay a name
Basically if the user clicks start, the progressbar steps up and at the same time filecount and the name are displayed parallely.
There's is another operation where if the user clicks pause it(thread) has to suspend until the user clicks resume.
The problem is,the above will not work(will not suspend and resume) for both thread..but works for a singlw thread.
Please check the code to get an idea and reply me what can done!
on button click start
void CThreadingEx3Dlg::OnBnClickedStart()
{
m_ProgressBar.SetRange(start,end);
myThread1 = AfxBeginThread((AFX_THREADPROC)MyThreadFunction1,this);
myThread2 = AfxBeginThread((AFX_THREADPROC)MyThreadFunction2,this);
}
thread1
UINT MyThreadFunction1(LPARAM lparam)
{
CThreadingEx3Dlg* pthis = (CThreadingEx3Dlg*)lparam;
for(int intvalue =pthis->start;intvalue<=pthis->end; ++intvalue)
{
pthis->SendMessage(WM_MY_THREAD_MESSAGE1,intvalue);
}
return 0;
}
thread1 function
LRESULT CThreadingEx3Dlg::OnThreadMessage1(WPARAM wparam,LPARAM lparam)
{
int nProgress= (int)wparam;
m_ProgressBar.SetPos(nProgress);
CString strStatus;
strStatus.Format(L"Thread1:Processing item: %d", nProgress);
m_Static.SetWindowText(strStatus);
Sleep(100);
return 0;
}
thread2
UINT MyThreadFunction2(LPARAM lparam)
{
CThreadingEx3Dlg* pthis = (CThreadingEx3Dlg*)lparam;
for(int i =pthis->start;i<=pthis->end;i++)
{
pthis->SendMessage(WM_MY_THREAD_MESSAGE2,i);
}
return 0;
}
thread2 function
LRESULT CThreadingEx3Dlg::OnThreadMessage2(WPARAM wparam,LPARAM lparam)
{
m_Static1.GetDlgItem(IDC_STATIC6);
m_Static1.SetWindowTextW(L"Thread2 Running");
Sleep(100);
m_Static1.SetWindowTextW(L"");
Sleep(100);
return TRUE;
}
void CThreadingEx3Dlg::OnBnClickedPause()
{
// TODO: Add your control notification handler code here
if(!m_Track)
{
m_Track = TRUE;
GetDlgItem(IDCANCEL)->SetWindowTextW(L"Resume");
myThread1->SuspendThread();
WaitForSingleObject(myThread1->m_hThread,INFINITE);
myThread2->SuspendThread();
m_Static.SetWindowTextW(L"Paused..");
}
else
{
m_Track = FALSE;
GetDlgItem(IDCANCEL)->SetWindowTextW(L"Pause");
myThread1->ResumeThread();
myThread2->ResumeThread();
/*myEventHandler.SetEvent();
WaitForSingleObject(myThread1->m_hThread,INFINITE);*/
}
}
I thought I should summarize some of the discussion in the comments into an answer.
In Windows programming, you should never try to manipulate a GUI control from a background thread, as doing so can cause your program to deadlock . This means only the main thread should ever touch elements of the GUI. (Technically, what matters is which thread created the control, but it's not common to create controls in background threads).
This requirement is detailed in Joe Newcomer's article on worker threads (see "Worker Threads and the GUI II: Don't Touch the GUI").
You are using SendMessage in your thread procedures. This causes the appropriate message handler for the target control to be invoked, but in the thread that called SendMessage. In your case, that means the background threads run the message handlers and therefore update the progress bar and label.
The alternative is to use PostMessage. This causes the message to be added to a queue to be processed by the main thread's message loop. When the main thread gets to run, it processes the messages in the order they were added to the queue, calling the message handlers itself. Since the main thread owns the windows, it is safe for it to update the controls.
You should also beware that SuspendThread and ResumeThread are tricky to get right. You might want to read this section of Joe Newcomer's article, which describes some of the dangers.
Tasks like this are often better achieved by using a timer. This is a mechanism for having the operating system notify your program when a particular amount of time has passed. You could implement this with a timer as below:
BEGIN_MESSAGE_MAP(CThreadingEx3Dlg, CDialog)
ON_WM_DESTROY()
ON_WM_TIMER()
END_MESSAGE_MAP()
void CThreadingEx3Dlg::OnTimer(UINT_PTR nTimerID)
{
static int progress = 0;
if (nTimerID == 1)
{
m_ProgressBar.SetPos(progress);
CString strStatus;
strStatus.Format(_T("Processing item: %d"), progress);
m_Static.SetWindowText(strStatus);
progress++;
if (progress > end) // If we've reached the end of the updates.
KillTimer(1);
}
}
BOOL CThreadingEx3Dlg::OnInitDialog()
{
// ... initialize controls, etc, as necessary.
SetTimer(1, 100, 0);
}
void CThreadingEx3Dlg::OnDestroy()
{
KillTimer(1);
}
If you want both updates handled at the same time, they can use the same timer. If they need to happen at different times (such as one at a 100 ms interval and another at a 150 ms interval) then you can call SetTimer twice with different IDs. To pause the action, call KillTimer. To resume it, call SetTimer again.
Multi-threading and message queuing is quite a complex game. When you SendMessage from ThreadA to the same thread then it just calls the message handler. If you do it from ThreadA to another thread (ThreadB) then it gets more complicated. ThreadA then posts a message to the ThreadB's message queue and waits on a signal to say that ThreadB has finished processing the message and sent the return value. This raises an instant problem. If ThreadB is not pumping messages then you have a deadlock as the message in ThreadB's will never get "dispatched". This also raises an EVEN bigger problem. If ThreadB's message needs to send a message to a control created in ThreadA then you have a massive architectural problem. As ThreadA is currently suspended waiting for ThreadB to return and ThreadB is suspended waiting for ThreadA to return. Nothing will happen ... They will both sit suspended.
Thats about it really. Its pretty easy as long as you bear these issues in mind. ie It absoloutely IS possible despite what the others have said.
In general though your threading is pretty pointless because you straight away send a message to the main thread to do some processing. Why bother starting the threads in the first place. You may as well not bother because the threads will just sit there waiting for the main thread to return.
Why do you "WaitForSingleObject" anyway when you suspend the first thread? Why not just suspend them both.
All round, though, you aren't giving enough information about what you are doing to say exactly whats going on. What happens when you click pause, for example?
Windows will not operate properly when more than one thread interacts with the GUI. You'll need to reorganize your program so that does not happen.