I'm working on a Windows-only wxWidgets GUI application that shall receive asynchronous notifications from a service process via a named pipe. I would like to avoid spawning a separate thread for pipe handle monitoring. Hence, I'm thinking about using overlapped IO. My question is: what would be the most straight-forward way of receiving notifications for the pipe handle in the main thread?
There is unfortunately no way to integrate an arbitrary HANDLE with wxWidgets event loop so the best solution is to use a separate thread and maybe call wxQueueEvent if you really need to modify the main thread.
Related
I need both event loops: one for Windows service (or Linux daemon) and another for Qt event queue QCoreApplication::exec() (or QApplication::exec() or even QEventLoop::exec()).
Can I have both at the same time in single thread? Or should I create a separate thread for one of them? In the latter case how should be arranged interaction process between QObjects and "window"/"service" thread?
Windows service requires either Message only window along with window procedure to receive and process a messages from the Windows, or Service Control Handler Function. I want to be able to process both kinds of events comes from the Windows and Qt-specific ones.
Can I use QEventLoop/QCoreApplication/QApplication::processEvents to process Qt events between events, that comes from a Windows? How can it affect service responsiveness and QTimer responsiveness?
Try to use QtService library. The QtService is useful for developing Windows services and Unix daemons:
https://github.com/qtproject/qt-solutions/tree/master/qtservice
Alternatively, you can realize it yourself like as in QtService library:
https://github.com/qtproject/qt-solutions/blob/master/qtservice/src/qtservice_win.cpp#L556
Qt event loop integrates native notifications/events on all platforms. The nativeEventFilter is how you react to native events when you wish to.
In my C++ application I'm using a third party library for Bluetooth discovering process. I'm looking at the examples provided to learn how to use it.
The example that best match my needs is a simple GUI application that call a Discovery(long timeout) function from the library to start the Bluetooth discovery.
That function returns immediatly (so that the GUI is not freezed) and fires an __event called OnDeviceFound once a new BT device has been discovered and OnDiscoveryComplete once the timeout has elapsed.
So in the GUI constructor (of the example) there're __hook defined like this:
__hook(&BluetoothDiscovery::OnDiscoveryComplete, &m_Discovery, &BluetoothClientDlg::OnDiscoveryComplete);
Now, I need to implement the same in my application, that is not a Window application but a console application that runs as a Windows Service, doing a continuos discovering on a separate thread looking for new devices.
So, actually, since my implementation makes use of a thread for discovery, I don't need an event based discovery procedure, but I need a blocking discovering. The library does not provide a blocking API for discovering.
So here comes the question: is it possible to use an event based function in a blocking function? In other words, is it possible to write a function that could be called in the thread main loop every n seconds that does a discovery procedure and return the founded Bluetooth devices (using that event-based library API)?
What you want is a Semaphore which your main thread sits on until the discovery thread completes and then notifies your main thread to wake.
Active waits like what you suggest are nasty, and should be avoided where you can.
I have a C++ console app that uses open() [O_RDWR | O_NONBLOCK], write(), select(), read() and close() to work with device file. Also ioctl() can be called to cancel current operation. At any given time only one user can work with device.
I need to come up with C++ class having libsigc++ signals that get fired when data is available from device.
The problem: when calling select() application becomes unresponsive as it waits for the data. How to make it responsive - by calling select() in worker thread? If so - how will worker thread communicate with main thread? Maybe I should look into boost::asio?
How to make it responsive - by calling select() in worker thread
you can use dup(), this will duplicated your file descriptors... thus you can move entire read operations into another thread. thus your write thread and processing thread will be responsive, even when the read [select()] thread is in sleeping.
signal emitting overhead of libsigc++ is minimal, thus i think you can embedded code inside the read thread itself. slots can exist in different thread, this is where you will receive your signals...
I think Thrift source code [entirely boost based] might be of your interest, though thrift does not use libsigc++.
It sounds as though you've misunderstood select; the purpose of select (or poll, epoll, etc) is not "wait for data" but "wait for one or more events to occur on a series of file descriptors or a timer, or a signal to be raised".
What "responsiveness" is going missing while you're in your select call? You said it's a console app so you're not talking about a GUI loop, so presumably it is IO related? If so, then you need to refactor your select so that waiting for the data you're talking about is one element; that is, if you're using select, build FD_SETs of ALL file/socket descriptors (and stdin and stdout are file descriptors) that you want to wait on input for.
Or build a loop that periodically calls "select" with a short timeout to /test/ for any pending input and only try and read it when select tells you there is something to read.
It sounds like you have a producer-consumer style problem. There are various way to implement a solution to this problem, but most folks these days tend to use condition variable based approaches (see this C++11 based example).
There are also a number of design patterns that when implemented can help alleviate your concurrency problem, such as:
Half-Sync / Half-Async
A producer-consumer style pattern that introduces a queue between an asynchronous layer that fills the queue with events, and a synchronous layer that processes those events.
Leader / Followers
Multiple threads take turns handling events
A related discussion is available here.
I have a QThread that reads from a socket and sends a signal (QT signal) when there are any data available.
This would be easy with blocking read(2), but i need to be able to stop the thread from outside without waiting for too long.
If I were using pthread I would use pselect and pthread_kill(thread_id, some_signal), but QThread doesn't
seem to have any similar methods. And adding a dependcy on pthread to this project doesn't seem to elegant.
I also don't want to use the other ugly methods like constantly trying to read from the socket with some relatively small timeout.
Edit: The sockets are not TCP, but bluetooth L2CAP.
A not too elegant, but simple and working solution:
Create a pipe and let select wait for either the pipe or my socket. This way I can stop the wait anytime by writing something to the pipe.
Instead of dealing with the threading yourself you can use the asynchronous interface of QTcpSocket. Check out the Fortune Client example.
You can send a signal to the terminate() slot of your QThread. This will stop your thread according to OS scheduling policies.
I have a Qt/C++ application, with the usual GUI thread, and a network thread. The network thread is using an external library, which has its own select() based event loop... so the network thread isn't using Qt's event system.
At the moment, the network thread just emit()s signals when various events occur, such as a successful connection. I think this works okay, as the signals/slots mechanism posts the signals correctly for the GUI thread.
Now, I need for the network thread to be able to call the GUI thread to ask questions. For example, the network thread may require the GUI thread to request put up a dialog, to request a password.
Does anyone know a suitable mechanism for doing this?
My current best idea is to have the network thread wait using a QWaitCondition, after emitting an object (emit passwordRequestedEvent(passwordRequest);. The passwordRequest object would have a handle on the particular QWaitCondition, and so can signal it when a decision has been made..
Is this sort of thing sensible? or is there another option?
Using signals to send messages between threads is fine, if you don't like using the Condition Variable, then you can send signals in both directions in a more-or-less asynchronous manner: this might be a better option if you want to continue processing network stuff while you wait for a reply from the GUI.