Multithreaded object destruction on closing MFC dialog - c++

So, this is the problem:
I have written a wrapper class exposing simplified API for the libtorrent c++ library. It (the wrapper) has a stack-allocated member, which is libtorrent's main session object.
The library itself uses boost framework, and its threading features - it is multithreaded. (I must say that I'm not really familiar with boost.)
Now, I wanted to create a simple MFC dialog-based application that will have a couple of buttons for managing the session, progress bar, etc.
The destructor of a libtorrent session may take a while to finish (since it needs to notify the trackers that it's closing). The user is prompted on exit with a MessageBox to confirm download termination, so I thought it was a good idea to put my wrapper object as a member of the app class, rather than the CDialog (the wrapper destructor, and consequently the session's will kick in after the dialog is closed). Libtorrent docs also state that it is a good idea to close UI such as windows before the destructor is invoked.
And here comes the fun part - everything works fine, until I close the dialog. The process continues to live for a couple of seconds, and then crashes with some boost-related locks/critical section stuff (that's where the debugger pointed, some lock / release call in one of the boost's headers)...
EDIT
Seems that while closing, some thread checks are performed from the main window, and it gets into some "irregular" state where it does something that makes the boost fail. I'm thinking some kind of a "join" is needed for the gui thread, to wait for other threads termination...
If anyone understood what I was trying to explain here, and has some idea what am I doing wrong, or has an alternative solution to this concept, I'd really appreciate it.
Thanks.

You can wait for the Boost threads to join prior to exiting. I have an Output_Processor class that uses a Boost thread. I interface to it through a queue. Once I want to shutdown the app, I put a shutdown command in its queue. The Output_Processor thread returns after processing that command. Then my block on join returns and the rest of the app can shutdown gracefully.
...
_output_processor_queue->write(shutdown_command);
// Wait for output processor thread to join.
_output_processor_thread->join();
_output_processor_initialized = false;
...

OK, the problem is resolved.
All I did is that I initially created a dynamic wrapper object, and deleted it after doModal() returns. At that point the main thread blocks, waiting till the deletion operation is over, which is basically until the libtorrent session is destructed. However, the peculiar behavior of non-dynamic object remains.

Related

Portable generic shared library setup with Qt event loop

We are trying to write a portable shared library that makes use of some Qt classes for convenience (mainly QTimer and QTcpSocket); no GUI stuff, though. The according signal/slot connections appear to require some Qt event loop, so we "prime" a QCoreApplication as outlined in this answer. Accordingly, we set up a worker object that does the heavy lifting and move it to a QThread.
The problem we run into now is that the queued connections between the QThread's owner object (within the main thread) and the worker object within the QThread seem to never get handled on Linux systems, at least as long as the program that implements our library does not provide any further Qt event loop of its own in the main thread. This is not very helpful, since the data passed from the worker to the main thread should be passed further using some callback functions, which now never get called, though.
My question is thus: is there a way to get an event loop to work in the library main thread without locking it or the host program up (which seems to be the case when just putting a QCoreApplication::exec() or similar there)? Or will we have to set up a different inter-thread communication scheme (independent from Qt) in order to deal with these data transfers?
Since we do not know if the host software is going to run on a QApplication or not, ideally I'd also have a check for that before setting up a main thread event loop. Is a simple if(qApp != nullptr) enough for that?
P.S.: A few things I tried but which did not work for me, either:
Settings up a QEventLoop in a std::thread launched from the main thread (probably not working because still not in the main thread)
Setting up a QEventLoop in the main thread class and triggering its processEvents() function periodically using a QTimer (probably not working due to the missing event loop for the QTimer::timeout signal in the main function)
Starting the QCoreApplication in a std::thread (gives a run-time warning on Windows that QCoreApplication should be started in the main thread)
In Qt parlance, a callback is called Qt::DirectConnection. But of course those callbacks will run on your worker thread. But that’d be the case with any other library that uses callbacks, so Qt is not a problem here, and neither is your code: the basic idea has this property.
If the host application is not using an event loop (any event loop, not necessarily Qt’s), then there’s nothing you can do other than polling – see below.
If the host application runs an X11 event loop, then you need to ensure that your copy of Qt is using the same underlying event loop as the host application. Usually, this would be the glib’s event loop, and then it should work automagically. Otherwise, you’ll need to pass to the user the file descriptor of the synchronization primitive used by Qt’s event loop, and the user will need to integrate it into their event loop. You’ll face the same problem whether you use Qt or not: rolling your own communication method won’t fix it, since you still need a waitable primitive that will interoperate with whatever event loop the user is using.
The user can of course poll for callbacks whenever they feel like it: expose a mainPoll() method that forwards to QCoreApplication::processEvents().
Despite accepting another answer (which I deem more correct), I'd still like to mention a workaround that worked surprisingly well: We actually managed to get around the event loop/thread problems on most systems by connecting the worker thread signals with lambda functions in constructor of the class that sets up the worker.
Now, I doubt that this behaviour is properly thread-safe, and having relatively lengthy lambda functions declared in connect function calls is certainly not good style. But in case anyone else ends up struggling with this issue, this may be a short-term solution or (temporary) workaround.

Should I use thread in my library?

I am implementing a function in library which takes a while (up to a minute). It initialize a device. Now generally any long function should run in its own thread and report to main thread when it completes but I am not sure since this function is in library.
My dilemma is this, even if I implement this in a separate thread, another thread in the application has to wait on it. If so why not let the application run this function in that thread anyways?
I could pass queue or mailbox to the library function but I would prefer a simpler mechanism where the library can be used in VB, VC, C# or other windows platforms.
Alternatively I could pass HWND of the window and the library function can post message to it when it completes instead of signaling any event. That seems like most practical approach if I have to implement the function in its own thread. Is this reasonable?
Currently my function prototype is:
void InitDevice(HANDLE hWait)
When initialization is complete than I signal bWait. This works fine but I am not convinced I should use thread anyways when another secondary thread will have to wait on InitDevice. Should I pass HWNDinstead? That way the message will be posted to the primary thread and it will make better sense with multithreading.
In general, when I write library code, I normally try to stay away from creating threads unless it's really necessary. By creating a thread, you're forcing a particular threading model on the application. Perhaps they wish to use it from a very simplistic command-line tool where a single thread is fine. Or they could use it from a GUI tool where things must be multi-threaded.
So, instead, just give the library user understanding that a function call is a long-term blocking call, some callback mechanism to monitor the progress, and finally a way to immediately halt the operation which could be used by a multi-threaded application.
What you do want to claim is being thread safe. Use mutexes to protect data items if there are other functions they can call to affect the operation of the blocking function.

boost::interprocess::named_mutex vs CreateMutex

I want to switch from CreatMutex to boost::interprocess::named_mutex to limit my application to a single instance. Both methods works when the application runs and ends just fine. However, the lock is not released when the application crashes and using boost::interprocess::named_mutex. I could resolve that issue by using two name_mutex but I don't really understand the issue.
Why is the lock for boost::interprocess::named_mutex not released when the application crashes but it is release with CreatMutex? What's the difference?
boost::interprocess::named_mutex mutex(boost::interprocess::open_or_create, "my_mutex");
boost::interprocess::scoped_lock<boost::interprocess::named_mutex> lock(mutex, boost::interprocess::try_to_lock);
if(!lock) {
return 1; //exit
}
//application may crash here.
boost::interprocess::named_mutex::remove("my_mutex");
return 1; //exit
Caveat: I've not spent much time with boost::interprocess, so this information is just from a quick inspection of the source. That said, I've used the Windows synchronisation API's a lot, so here goes...
The main difference between the two methods of interprocess synchronisation is how the object exists within the system.
With boost::interprocess::named_mutex, as well as a system-specific mutex, it looks like a synchronisation object is created as a file on the system. The location of the file is based on Registry entries (see note 1) (at least in Boost 1.54.0)... it's most likely located under the Common Application Data folder (see note 2). When the aplication crashes, this file is, in your case, not removed. I'm not sure if this is by design... however in the case of an application crash, it's perhaps best not to mess with the file system, just in case.
Conversely, when you use CreateMutex, an object is created at the kernel mode, which for named mutexes can be accessed by several applications. You get a handle to the Mutex by specifying the name when you create it, and you lose the handle when you call CloseHandle on it. The mutex object is destroyed when there are no more handles referencing it.
The important part of this is in the documentation:
The system closes the handle automatically when the process terminates. The mutex object is destroyed when its last handle has been closed.
This basically means that Windows will clean up after your application.
Note that if you don't perform a ReleaseMutex, and your application owns the mutex when it dies, then it's possible/likely that a waiting thread or process would see that the mutex had been abandoned (WaitForSingleObject returns WAIT_ABANDONED), and would gain ownership.
I apologise for not providing a solution, but I hope it answers your question about why the two systems act differently.
Just as an aside, using registry entries to get this information is horrible - it would be safer, and more future-proof, to use SHGetKnownFolderPath. But I digress.
Depending on your OS version, this could be %ALLUSERSPROFILE%\Application Data\boost.interprocess or ProgramData\boost.interprocess, or somewhere else entirely.
What you want is not trivial and the interprocess_mutex definitively the wrong way to do.
What you may could do is remove the mutex on termination, by providing a remover destructor and/or in a catch(...). But this is not guaranteed to work, since it won't be done if you terminate the process directly (from the OS). Also it could accidently remove the mutex while your application starts twice.
One approach is to safe the process-id (for example in a shared memory) on the first time your program starts and remove it when it stops. Everytime you start the application read and check if the id still in process, if not, start the program.

WinForm-style Invoke() in unmanaged C++

I've been playing with a DataBus-type design for a hobby project, and I ran into an issue. Back-end components need to notify the UI that something has happened. My implementation of the bus delivers the messages synchronously with respect to the sender. In other words, when you call Send(), the method blocks until all the handlers have called. (This allows callers to use stack memory management for event objects.)
However, consider the case where an event handler updates the GUI in response to an event. If the handler is called, and the message sender lives on another thread, then the handler cannot update the GUI due to Win32's GUI elements having thread affinity. More dynamic platforms such as .NET allow you to handle this by calling a special Invoke() method to move the method call (and the arguments) to the UI thread. I'm guessing they use the .NET parking window or the like for these sorts of things.
A morbid curiosity was born: can we do this in C++, even if we limit the scope of the problem? Can we make it nicer than existing solutions? I know Qt does something similar with the moveToThread() function.
By nicer, I'll mention that I'm specifically trying to avoid code of the following form:
if(! this->IsUIThread())
{
Invoke(MainWindowPresenter::OnTracksAdded, e);
return;
}
being at the top of every UI method. This dance was common in WinForms when dealing with this issue. I think this sort of concern should be isolated from the domain-specific code and a wrapper object made to deal with it.
My implementation consists of:
DeferredFunction - functor that stores the target method in a FastDelegate, and deep copies the single event argument. This is the object that is sent across thread boundaries.
UIEventHandler - responsible for dispatching a single event from the bus. When the Execute() method is called, it checks the thread ID. If it does not match the UI thread ID (set at construction time), a DeferredFunction is allocated on the heap with the instance, method, and event argument. A pointer to it is sent to the UI thread via PostThreadMessage().
Finally, a hook function for the thread's message pump is used to call the DeferredFunction and de-allocate it. Alternatively, I can use a message loop filter, since my UI framework (WTL) supports them.
Ultimately, is this a good idea? The whole message hooking thing makes me leery. The intent is certainly noble, but are there are any pitfalls I should know about? Or is there an easier way to do this?
I have been out of the Win32 game for a long time now, but the way we used to achieve this was by using PostMessage to post a windows message back to the UI thread and then handle the call from there, passing the additional info you need in wParam/lParam.
In fact I wouldn't be surprised if that is how .NET handles this in Control.Invoke.
Update: I was currios so I checked with reflector and this is what I found.
Control.Invoke calls MarshaledInvoke which does a bunch of checkes etc. but the interesting calls are to RegisterWindowMessage and PostMessage. So things have not changed that much :)
A little bit of follow-up info:
There are a few ways you can do this, each of which has advantages and disadvantages:
The easiest way is probably the QueueUserAPC() call. APCs are a bit too in-depth to explain, but the only drawback is they may run when you're not ready for them if the thread gets put into an alertable wait state accidently. Because of this, I avoided them. For short applications, this is probably OK.
The second way involves using PostThreadMessage(), as previously mentioned. This is better than QueueUserAPC() in that your callbacks aren't sensitive to the UI thread being in an alertable wait state, but using this API has the problem of your callbacks not being run at all. See Raymond Chen's discussion on this. To get around this, you need to put a hook on the thread's message queue.
The third way involves setting up an invisible, message-only window whose WndProc calls the deferred call, and using PostMessage() for your callback data. Because it is directed at a specific window, the messages won't get eaten in modal UI situations. Also, message-only windows are immune to system message broadcasts (thus preventing message ID collisions). The downside is it requires more code than the other options.

boost::thread causing small event handle leak?

I'm debugging this database project. It wraps access to SQLite for a higher level application. It's designed to run asynchronously, that is, it has methods like ExecuteRequestAsync() and IsRequestReady(). When ExecuteRequestAsync is called, it spawns a boost::thread to do the job and return the function immediately. When the higher level application decides that it no longer wants the result of a running request, it may call DumpRequest() to cancel it. Since it's difficult to gracefully cancel a database request, the implementation of DumpRequest just maintain a "cleanup monitor thread" that waits for "finished requests" and remove them. All boost::threads are managed through boost::shared_ptr, like:
boost::shared_ptr<boost::thread> my_thread = new boost::thread(boost::bind(&DBCon::RunRequest, &this_dbcon));
And when it's no longer needed (to be canceled):
vector<boost::shared_ptr<boost::thread> > threads_tobe_removed;
// some iteration
threads_tobe_removed[i].get()->join();
threads_tobe_removed.erase(threads_tobe_removed.begin()+i);
I created this unit test project to test the mechanism of executing and dumping the requests. It runs requests and randomly cancels running requests, and repeats for several thousand passes. The mechanism turned out to be okay. Everything worked as expected.
However, through observing the unit test project through sysinternal's Process Explorer, it's discovered that there's a handle leak problem. Every 500-ish passes, the handle count increases by 1, and never returns back. It's the "Event" type handle that is increasing. File and thread handles are not increasing (of course # of handles are increasing as threads are spawned, but there is a Sleep(10000) call every hundred passes to wait for them to be cleaned up so that the handle count can be observed).
I haven't been managing Event handles myself. They are created by boost::thread upon the creation of the thread. I only guarantee to gracefully close the threads, I have no idea what the Events are used for.
I'm wondering if anyone has experienced similar problems? What might be the cause of this leak? Is this number in Process Explorer reliable enough to call it a handle leak? Is there any way to trace and fix it?
I'm using statically linked boost 1.40 on Windows Vista, with Visual C++.
Is the access to threads_tobe_removed thread-safe? If not, there may be a race condition, when one thread adds a thread to the vector via a call to DumpRequest, while the cleanup monitor thread deletes a thread from the vector. Thus, boost::thread-objects may be destroyed without joining the thread first, which would leave the thread running without an associated object, which might explain the leak.