I would like to know how to design a system that can offer a solid framework to handle signals and the connection between the signal/s and the method/s without writing a really unpleasant cycle that iterates over and over with some statement for forking the flow of the application.
In other words I would like to know the theory behind the signal slot mechanism of Qt or similar.
I'm naming Qt for no particular reason, it's just probably one of the most used and well tested library for this so it's a reference in the C++ world, but any idea about the design of this mechanism will be good.
Thanks.
At a high level, Qt's signal/slots and boost's signal library work like the Observer Pattern (they just avoid needing an Observer base class).
Each "signal" keeps track of what "slots" are observing it, and then iterates over all of them when the signal is emitted.
As for how to specifically implement this, the C++ is pretty similar to the Java code in the Wikipedia article. If you want to avoid using an interface for all observers, boost uses templates and Qt uses macros and a special pre-compiler (called moc).
It sounds like you are asking for everything but without any losses.
There are a few general concepts that I am aware of for handling asynchronous input and changes such as "keys being pressed" and "touch events" and "an object that changes its own state".
Most of these concepts and mechanisms are useful for all sorts of program flow and can cross lots of boundaries: process, thread, etc. This isn't the most exhaustive list but they cover many of the ones I've come across.
State Machines
Threads
Messages
Event Loops
Signals and Slots
Polling
Timers
Call Back Functions
Hooking Input
Pipes
Sockets
I would recommend researching these in Wikipedia or in the Qt Documentation or in a C++ book and see what works or what mechanism you want to work into your framework.
Another really good idea is to look at how programming architects have done it in the past, such as in the source of Linux or how the Windows API lets you access this kind of information in their frameworks.
Hope that helps.
EDIT: Response to comment/additions to the question
I would manage a buffer/queue of incoming coordinates, and have an accessor for the latest coordinate. Then I would keep track of events such as the start of a touch/tap/drag and the end of one, and have some sort of timer for when a long touch is performed, and a minimum change measurement for when a dragged touch is performed.
If I am using this with just one program, I would try to make a interface that is similar to what I could find in use. I've heard of OpenSoundControl being used for this kind of input. I've set up a thread that collects the coordinates and keeps track of the events. Then I poll for that information in the program/class that needs to use it.
Related
I'm struggling with a GUI application in C++.
Clicking buttons activates routines, which may take some time. The window is then unresponsive.
I would like it to keep listening and reactive.
I heard about ISR, which seems unsuitable because I don't want to continue where I left, but rather forget about the aborted procedure and start fresh.
Please don't be harsh on me.
I'd be glad if you can point me to somewhere useful. I've literally spent two hours finding nothing helpful (for me, might be my fault).
The exact solution is going to be very dependent on what you're trying to do, and what (toolkit, etc) you're trying to do it with.
The quick (to give, not to do) answer is to use a separate thread for your work. You have one thread for your GUI stuff, and when the user hits a button you send a message to your worker thread from your GUI thread.
If you're on C++11 or up, you can use std::thread to implement threads. Otherwise, you'll have to use whatever is available on your platform. These APIs are usually quite low level.
std::async has a slightly higher level of operation. The GUI toolkit you're working with might have something. Whatever you choose, it's never going to be as 'simple' as a synchronous, single threaded program.
In general, the earlier you think about your threading strategy in the design of a piece of software, the easier it is to implement. Adding multithreading to a well established program is often very difficult.
Apologies if this is more 'vague' than you were hoping for. Perhaps if you add more details about platform and toolkits, people will be able to make more specific suggestions?
Best of luck!
I am currently in the process of refactoring an mid-sized software project. It contains a central kernel-like class that is used by multiple threads. Currently, this class uses a Glib::Dispatcher for handling signals that are emitted by multiple threads. Since one goal of the refactoring proccess is to get rid of glibmm entirely (since Qt shall be used as the new framework), I am trying to figure out a way of how to "simulate" the dispatcher functionality using Boost. I already looked into Boost.Signals and Boost.Signals2, but neither one of these libraries seems to offer an alternative to the dispatcher.
To clarify what the dispatcher shall do, here's a short description from the official documentation:
Glib::Dispatcher works similar to sigc::signal. But unlike
normal signals, the notification happens asynchronously through a
pipe. This is a simple and efficient way of communicating between
threads, and especially useful in a thread model with a single GUI
thread.
No mutex locking is involved, apart from the operating system's
internal I/O locking. That implies some usage rules:
Only one thread may connect to the signal and receive notification, but multiple
senders are allowed even without locking.
The GLib main loop must run in the receiving thread (this will be the GUI thread usually).
The Dispatcher object must be instantiated by the receiver thread.
The Dispatcher object should be instantiated before creating any of the
sender threads, if you want to avoid extra locking.
The Dispatcher object must be deleted by the receiver thread.
All Dispatcher objects instantiated by the same receiver thread must use the same main
context.
Could you give me some pointers in the right direction? Is this the sort of functionality I can achieve using Boost.Signals or Boost.Signals2?
Edit: As a commenter rightly pointed out, using Qt would perhaps be an option. However, the class that I am refactoring is very low-level and I do not want to add this additional dependency.
I think there is no simple way to do that, removing Glib in flavour of boost won't solve the problem which is more an architechtural issue than anything else. Replacing with Boost not gonna fix the design issue.
You should model your own signal interface, and try to adapt for each library, including Glib in the first place since it is already working, adding another indirection level to your problem will let you fix that issue.
Boost can help you if you look at boost::function. I dont consider replacing glib with boost to be a real step forward, boost is not a graphical library and it will be required at some point to add an interface with an implementation layer to your graphic engine.
I have now opted for a total rewrite of the class in question. It turns out that I do not require the dispatcher functionality in the way it was provided by Glib. Instead, it was enough to use the normal boost::signals2 signals, coupled with some signals from Qt for the actual graphical interaction.
I have implemented a WebSocket handler in C++ and I need to send ping messages once in a while. However, I don't want to start one thread per socket/one global poll thread which only calls the ping function but instead use some OS functionality to call my timer function. On Windows, there is SetTimer but that requires a working message loop (which I don't have.) On Linux there is timer_create, which looks better.
Is there some portable, low-overhead method to get a function called periodically, ideally with some custom context? I.e. something like settimer (const int millisecond, const void* context, void (*callback)(const void*))?
[Edit] Just to make this a bit clearer: I don't want to have to manage additional threads. On Windows, I guess using CreateThreadpoolTimer on the system thread pool will do the trick, but I'm curious to hear if there is a simpler solution and how to port this over to Linux.
If you are intending to go cross-platform, I would suggest you use a cross platform event library like libevent.
libev is newer, however currently has weak Win32 support.
If you use sockets, you can use select, to wait sockets events with timeout,
and in this loop calc time and call callback in suitable time.
If you are looking for a timer that will not require an additional thread, let you do your work transparently and then call the timer function at the appropriate time in the same thread by pre-emptively interrupting your application, then there is no such portable thing.
The first reason is that it's downright dangerous. That's like writing a multi-threaded application with absolutely no synchronization. The second reason is that it is extremely difficult to have good semantics in multi-threaded applications. Which thread should execute the timer callback?
If you're writing a web-socket handler, you are probably already writing a select()-based loop. If so, then you can just use select() with a short timeout and check the different connections for which you need to ping each peer.
Whenever you have asynchronous events, you should have an event loop. This doesn't need to be some system default one, like Windows' message loop. You can create your own. But you should be using it.
The whole point about event-based programming is that you are decoupling your code handling to deal with well-defined functional fragments based on these asynchronous events. Without an event loop, you are condemning yourself to interleaving code that get's input and produces output based on poorly defined "states" that are just fragments of procedural code.
Without a well-defined separation of states using an event-based design, code quickly becomes unmanageable. Because code pauses inside procedures to do input tasks, you have lifetimes of objects that will not span entire procedure scopes, and you will begin to write if (nullptr == xx) in various places that access objects created or destroyed based on events. Dispatch becomes comnbinatorially complex because you have different events expected at each input point and no abstraction.
However, simply using an event loop and dispatch to state machines, you've decreased handling complexity to basic management of handlers (O(n) handlers versus O(mn) branch statements with n types of events and m states). You decouple handling but still allow for functionality to change depending on state. But now these states are well-defined using state classes. And new states can be added if the requirements of the product change.
I'm just saying, stop trying to avoid an event loop. It's a software pattern for very important reasons, all of which have to do with producing professional, reusable, scalable code. Use Boost.ASIO or some other framework for cross platform capabilities. Don't get in the habit of doing it wrong just because you think it will be less of an effort. In the end, even if it's not a professional project that needs maintenance long term, you want to practice making your code professional so you can do something with your skills down the line.
I am looking for a cross-platform C++ master/worker library or work queue library. The general idea is that my application would create some sort of Task or Work objects, pass them to the work master or work queue, which would in turn execute the work in separate threads or processes. To provide a bit of context, the application is a CD ripper, and the the tasks that I want to parallelize are things like "rip track", "encode WAV to Mp3", etc.
My basic requirements are:
Must support a configurable number of concurrent tasks.
Must support dependencies between tasks, such that tasks are not executed until all tasks that they depend on have completed.
Must allow for cancellation of tasks (or at least not prevent me from coding cancellation into my own tasks).
Must allow for reporting of status and progress information back to the main application thread.
Must work on Windows, Mac OS X, and Linux
Must be open source.
It would be especially nice if this library also:
Integrated with Qt's signal/slot mechanism.
Supported the use of threads or processes for executing tasks.
By way of analogy, I'm looking for something similar to Java's ExecutorService or some other similar thread pooling library, but in cross-platform C++. Does anyone know of such a beast?
Thanks!
I haven't used it in long enough that I'm not positive whether it exactly meets your needs, but check out the Adaptive Communications Environment (ACE). This library allows you to construct "active objects" which have work queues and execute their main body in their own threads, as well as thread pools that can be shared amoung objects. Then you can pass queue work objects on to active objects for them to process. Objects can be chained in various ways. The library is fairly heavy and has a lot to it to learn, but there have been a couple of books written about it and theres a fair amount of tutorial information available online as well. It should be able to do everything you want plus more, my only concern is whether it possesses the interfaces you are looking for 'out of the box' or if you'd need to build on top of it to get exactly what you are looking for.
I think this calls for intel's Threading Building Blocks, which pretty much does what you want.
Check out Intels' Thread Building Blocks library.
Sounds like you require some kind of "Time Sharing System".
There are some good open source ones out there, but I don't know
if they have built-in QT slot support.
This is probably a huge overkill for what you need but still worth mentioning -
BOINC is a distributed framework for such tasks. There's a main server that gives out tasks to perform and a cloud of workers that do its bidding. It is the framework behind projects like SETI#Home and many others.
See this post for creating threads using the boost library in C++:
Simple example of threading in C++
(it is a c++ thread even though the title says c)
basically, create your own "master" object that takes a "runnable" object and starts it running in a new thread.
Then you can create new classes that implement "runnable" and throw them over to your master runner any old time you want.
I am currently working on a server application that needs to control a collection devices over a network. Because of this, we need to do a lot of parallel programming. Over time, I have learned that there are three approaches to communication between processing entities (threads/processes/applications). Regrettably, all three approaches have their disadvantages.
A) You can make a synchronous request (a synchronous function call). In this case, the caller waits until the function is processed and the response has been received. For example:
const bool convertedSuccessfully = Sync_ConvertMovie(params);
The problem is that the caller is idling. Sometimes this is just not an option. For example, if the call was made by the user interface thread, it will seem like the application has blocked until the response arrives, which can take a long time.
B) You can make an asynchronous request and wait for a callback to be made. The client code can continue with whatever needs to be done.
Async_ConvertMovie(params, TheFunctionToCallWhenTheResponseArrives);
This solution has the big disadvantange that the callback function necessarily runs in a separate thread. The problem is now that it is hard to get the response back to the caller. For example, you have clicked a button in a dialog, which called a service asynchronlously, but the dialog has been long closed when the callback arrives.
void TheFunctionToCallWhenTheResponseArrives()
{
//Difficulty 1: how to get to the dialog instance?
//Difficulty 2: how to guarantee in a thread-safe manner that
// the dialog instance is still valid?
}
This in itself is not that big a problem. However, when you want to make more than one of such calls, and they all depend on the response of the previous one, this becomes in my experience unmanageably complex.
C) The last option I see is to make an asynchronous request and keep polling until the response has arrived. In between the has-the-response-arrived-yet checks, you can do something useful. This is the best solution I know of to solve the case in which there is a sequence of asynchronous function calls to make. This is because it has the big advantage that you still have the whole caller context around when the response arrives. Also, the logical sequence of the calls remains reasonably clear. For example:
const CallHandle c1 = Sync_ConvertMovie(sourceFile, destFile);
while(!c1.ResponseHasArrived())
{
//... do something in the meanwhile
}
if (!c1.IsSuccessful())
return;
const CallHandle c2 = Sync_CopyFile(destFile, otherLocation);
while(!c1.ResponseHasArrived())
{
//... do something in the meanwhile
}
if (c1.IsSuccessful())
//show a success dialog
The problem with this third solution is that you cannot return from the caller's function. This makes it unsuitable if the work you want to do in between has nothing to do at all with the work you are getting done asynchronously. For a long time I am wondering if there is some other possibility to call functions asynchronously, one that doesn't have the downsides of the options listed above. Does anyone have an idea, some clever trick perhaps?
Note: the example given is C++-like pseudocode. However, I think this question equally applies to C# and Java, and probably a lot of other languages.
You could consider an explicit "event loop" or "message loop", not too different from classic approaches such as a select loop for asynchronous network tasks or a message loop for a windowing system. Events that arrive may be dispatched to a callback when appropriate, such as in your example B, but they may also in some cases be tracked differently, for example to cause transactions in a finite state machine. A FSM is a fine way to manage the complexity of an interaction along a protocol that requires many steps, after all!
One approach to systematize these consideration starts with the Reactor design pattern.
Schmidt's ACE body of work is a good starting point for these issues, if you come from a C++ background; Twisted is also quite worthwhile, from a Python background; and I'm sure that similar frameworks and sets of whitepapers exist for, as you say, "a lot of other languages" (the Wikipedia URL I gave does point at Reactor implementations for other languages, besides ACE and Twisted).
I tend to go with B, but instead of calling forth and back, I'd do the entire processing including follow-ups on a separate thread. The main thread can meanwhile update the GUI and either actively wait for the thread to complete (i.e. show a dialog with a progress bar), or just let it do its thing in the background and pick up the notification when it's done. No complexity problems so far, since the entire processing is actually synchronous from the processing thread's point of view. From the GUI's point of view, it's asynchronous.
Adding to that, in .NET it's no problem to switch to the GUI thread. The BackgroundWorker class and the ThreadPool make this easy as well (I used the ThreadPool, if I remember correctly). In Qt, for example, to stay with C++, it's quite easy as well.
I used this approach on our last major application and am very pleased with it.
Like Alex said, look at Proactor and Reactor as documented by Doug Schmidt in Patterns of Software Architecture.
There are concrete implementations of these for different platforms in ACE.