I'm building a Qt windows application that needs to react to data being written to its stdin.
I realise I could use blocking threads or polling timers here, but it seems like this should be doable using QWinEventNotifier.
However, if I initialise a notifier as notifier_ = new QWinEventNotifier(GetStdHandle(STD_INPUT_HANDLE));, this notifier seems to emit activated constantly, regardless of whether or not there is any data available to be read.
What am I missing? Do I need to manually reset the event somehow? Is there a different handle I should be using?
The consequence here is that when I then try to read from stdin when this signal is emitted, the calls block forever - the stdin stream is still open, but not enough data is available to be read, so the calls don't return until more is written. Does Qt provide any tools that would let me avoid getting stuck like this without resorting to messily terminating threads?
Related
I'm working on a Qt native messaging host for a chrome extension on windows.
The circumstances seem to be as follows:
There's no way to tell, before attempting to read, whether data is available or how much data is available to be read on stdin.
Making a read call, e.g. via a QFile that has opened the stdin handle, will block forever until enough data is written to stdin to satisfy it.
So it looks like this will involve a thread resigned to staying in these blocking read calls waiting for data to be written. The only option I can see for ending this operation is to call terminate() on the QThread, which is highly discouraged. Is there a better way of interrupting an endlessly blocking call? What are the consequences of terminating the thread - does the object that was running on it still exist, and would I be able to salvage it to perform cleanup?
I wanted to know how I can I make the io do something like a thread.join() wait for all tasks to finish.
io_type->post( strand->wrap(boost::bind &somemethod,ptr,parameter)));
In the above code if 4 threads were initially launched this would give work to the next available thread. However I want to know how I could actually wait for all the threads to finish work. Like we do with threads.join().
If this really needs to be done, then you could setup a mutex or critical section to stop your io handlers from processing messages off of the socket. This would need to be activated from another thread. But, more importantly...
Perhaps you should rethink your design. The problem with having the io wait for other threads to finish is that the io would then be unresponsive. In general, not a good idea. I suspect that most developers working on networking software would not even consider it. If you are receiving messages that are not ready to be processed yet due to other processing that is going on, then consider storing them in a queue and process them on a different thread when the other threads have signaled that they have completed their work.
I have a TIdCmdTCPClient which receives commands teminated in LF from a tcp server (written in C) into commandhandlers and accordingly updates a UI using TIdNotify. All is fine if it was not that somtimes I need to talk to the server in the traditional way using writeln and readln. If I try to do it there are problems such as the UI freezes, subsequent commands arrive later etc.
IS there a specific way to make work the pair writeln-readln just fine with TIdCmdTCPClient as they work with TIdTCPClient?
Please provide more informmation about the protocol you are implementing. You can certainly issue additional WriteLn() and ReadLn() calls while you are inside of a command handler event, as long as that is what the server is expecting you to do. But if you need to call ReadLn() out-of-band then you are going to conflict with TIdCmdTCPClient's internal reading.
I've got a Cocoa foundation tool that I run as a LaunchDeamon. When the app is terminated by the system, either by a reboot or shutdown (or even launchctl unload), is there a way I can capture this event so that I can perform some finalizing functions?
All the cases you're discussing send SIGTERM to the process. You want to add a signal handler for that. See the man pages for signal and sigaction. Read the warnings carefully. Only certain functions are legal to call during a signal handler (and in principle you should never allocate heap memory). Generally it's best to just use the handler to set a flag that tells your main thread to terminate.
You may also want to look at PreLoginAgents for an example of how to handle SIGTERM using the run loop, if you're using a run loop.
See Terminating Processes in the Daemons and Services Programming Guide for full details on what signals will be sent to your process.
All NSObject subclasses call a method before dying: - finalize. There is also NSSetUncaughtExceptionHandler for dealing with crashes.
What is Windows' best I/O event notification facility?
By best I mean something that ...
doesn't have a limit on number of input file descriptors
works on all file descriptors (disk files, sockets, ...)
provides various notification modes (edge triggered, limit triggered)
In Windows, async operations are done by file operation, not by descriptor. There are several ways to wait on file operations to complete asynchronously.
For example, if you want to know when data is available on a network socket, issue an async read request on the socket and when it completes, the data was available and was retrieved.
In Win32, async operations use the OVERLAPPED structure to contain state about an outstanding IO operation.
Associate the files with an IO Completion Port and dispatch async IO requests. When an operation completes, it will put a completion message on the queue which your worker thread(s) can wait on and retrieve as they arrive. You can also put user defined messages into the queue. There is no limit to how many files or queued messages can be used with a completion port
Dispatch each IO operation with an event. The event associated with an operation will become signaled (satisfy a wait) when it completes. Use WaitForMultipleObjects to wait on all the events at once. This has the disadvantage of only being able to wait on MAXIMUM_WAIT_OBJECTS objects at once (64). You can also wait on other types of events at the same time (process/thread termination, mutexes, events, semaphores)
Use a thread pool. The thread pool can take an unlimited number of objects and file operations to wait on and execute a user defined function upon completion each.
Use ReadFileEx and WriteFileEx to queue Asynchronous Procedure Calls (APCs) to the calling thread and SleepEx (or WaitFor{Single|Multiple}ObjectsEx) with Alertable TRUE to receive a notification message for each operation when it completes. This method is similar to an IO completion port, but only works for one thread.
The Windows NT kernel makes no distinction between socket, disk file, pipe, etc. file operations internally: all of these options will work with all the file types.
libuv
libuv offers evented I/O for Unix and Windows and has support for socket, files and pipes. It is the platform layer of Node.js.
More details are at: http://nikhilm.github.io/uvbook/introduction.html
There isn't one yet, as far as I am aware. A friend and I are working on an open source Windows epoll implementation (link below) but we're running into issues figuring out how to make it act the same as the Linux implementation.
Current obstacles:
In Linux, file descriptors and socket descriptors are interchangeable, but in Windows they are not. Both must be compatible with an epoll implementation.
In Windows it's quite tricky to get kernel events... which is how epoll works in Linux. We're guessing that a program using our cross-platform epoll library will run noticeably slower in Windows than Linux.
I'll try to come back and update this post as we make progress with the project.
http://sourceforge.net/projects/cpoll
select() function is POSIX and usable on windows including "winsock.h" or "winsock2.h".