How can I read/write to a device in C++? the device is in /dev/ttyPA1.
I thought about fstream but I can't know if the device has output I can read without blocking the application.
My goal is to create and application where you write something into the terminal and it gets sent into /dev/ttyPA1. If the device has something to write back it will read it from the device and write to screen. If not it will give the user prompt to write to the device again.
How can I do this?
Use open(2), read(2), and write(2) to read from and write to the device (and don't forget to close(2) when you're done). You can also use the C stdio functions (fopen(3) and friends) or the C++ fstream classes, but if you do so, you almost definitely want to disable buffering (setvbuf(3) for stdio, or outFile.rdbuf()->pubsetbuf(0, 0) for fstreams).
These will all operate in blocking mode, however. You can use select(2) to test if it's possible to read from or write to a file descriptor without blocking (if it's not possible, you shouldn't do so). Alternatively, you can open the file with the O_NONBLOCK flag (or use fcntl(2) to set the flag after opening) on the file descriptor to make it non-blocking; then, any call to read(2) or write(2) that would block instead fails immediately with the error EWOULDBLOCK.
For example:
// Open the device in non-blocking mode
int fd = open("/dev/ttyPA1", O_RDWR | O_NONBLOCK);
if(fd < 0)
; // handle error
// Try to write some data
ssize_t written = write(fd, "data", 4);
if(written >= 0)
; // handle successful write (which might be a partial write!)
else if(errno == EWOULDBLOCK)
; // handle case where the write would block
else
; // handle real error
// Reading data is similar
You can use fstream, but you're going to have to look up the specifications for how your device would like to receive data. Some devices will be just fine using ASCII data, other devices will need a specific binary sequence of data bits/bytes. You may also have to write custom serialization objects that overload the operator<< and operator>> functions for the data you're trying to write. Either that, or you could use the read() and write() methods to read/write raw binary data from/to buffer arrays you've allocated in your program.
Edit: if you're concerned about blocking behavior, then you have two choices. You will either have to use the POSIX API, and check your opened file-descriptor with either poll() or select() to see if data is available, or you will have to keep any file-writing or reading calls in a set of separate threads that can basically act as asynchronous read/write actions. So you would basically send a message to the reader/writer thread, and that thread would block if needed on the fstream calls, yet the rest of your program could continue to function. Your program though may not be designed for threads, and if that's the case, then the POSIX API would be the only way to-go.
Related
I'm an intermediate C++ programmer, but I'm new to using Windows' API functions.
I'm trying to create a console program that will sit/sleep until either
The user inputs something in the console and presses enter
Serial data is received on a serial port that's already been opened
Searching around, it sounds like the way to do this in Windows is with Events, (which sound like they're the same basic idea as interrupts?)
I found documentation on the WaitCommEvent, and I've read about reading console input buffer events. I'm guessing the function to use is WaitForMultipleObjects, but what handles specifically do I send it so it will wait for both a serial RX event or a console standard input event?
UPDATE:
Thanks for the response!
Currently I've just been using std::cin/cout to read from and write to the console. I looked over the Console API you mentioned and saw the GetStdHandle function which will give the CONIN$ handle you mentioned. Can I just send that CONIN$handle to the wait function instead of using CreateFile and manually using ReadFile/the Console API like you suggested?
For the Serial, I know how to open my serial handle as OVERLAPPED instead of as NONOVERLAPPED, but I'm not sure what you mean by
it is not usually too difficult to modify synchronous I/O code to use
an asynchronous handle
Something like this?
uint32 read(HANDLE serialHandle, uint8* pBuffer, int32 bufferLenght)
{
DWORD dwBytesRead;
if (!ReadFile(SerialHandle, pBuffer, bufferLength, &dwBytesRead, NULL))
{ /*ERROR*/ }
else
{
// Wait on some flag or variable until read is complete
// to make this call synchronous/NONOVERLAPPED ?
return static_cast<uint32>(dwBytesRead);
}
}
What/where would that flag be to wait on until the read is complete?
From Low-Level Console Input Functions on MSDN:
A thread of an application's process can perform a wait operation to wait for input to be available in an input buffer. To initiate a wait operation, specify a handle to the input buffer in a call to any of the wait functions.
So you need to use a console handle, which you can obtain by calling CreateFile on CONIN$. You will also need to use the same handle, either with ReadFile or the console API, to read the console input; using runtime library functions is likely to mess you up due to buffering.
For the serial port, I believe you will need to use asynchronous I/O. The WaitCommEvent function (when provided with an asynchronous mode handle) accepts an OVERLAPPED structure containing a handle to a manual-reset event object. You would then use the same event handle in the call to WaitForMultipleObjects.
Unfortunately this is an all-or-nothing, so you have to open the COM handle in asynchronous mode and use asynchronous I/O exclusively. (Luckily, it is not usually too difficult to modify synchronous I/O code to use an asynchronous handle, although if there are a lot of I/O calls you might want to write a wrapper function to do the repetitive work of building the OVERLAPPED structure and waiting for the operation to complete.)
This code, which I have no control over, reads a file using overlapped I/O:
// Read file asynchronously
HANDLE hFile = CreateFile(..., FILE_FLAG_OVERLAPPED, ...);
BYTE buffer[10];
OVERLAPPED oRead = { 0 };
ReadFile(hFile, buffer, 10, NULL, &oRead);
// Do work while file is being read
...
// Wait for read to finish
WaitForSingleObject(hFile, INFINITE);
// ReadFile has finished
// buffer now contains data which can be used
...
In another thread (actually in an API hook of ReadFile), I need to signal the hFile to unblock the WaitForSingleObject. Normally Windows (or the device driver handling the ReadFile) does this, but I need to simulate it.
None of the APIs I found that normally do this work with hFile, including ReleaseMutex, ReleaseSemaphore, and SetEvent. They all return Error 6 (handle is invalid). Is there an API that works with a file, named pipe, or communications device?
I know it is not recommended to WaitForSingleObject(hFile), but the above code is a given, and I need to work with it. Thanks!
So far as I know, signaling the file handle takes place internally to Windows, and there is no API even when running in kernel mode. (I believe the file system driver simply tells Windows that the operation is complete and lets Windows figure out how to notify the user-mode process. I may be wrong.)
One resolution would be to issue a genuine ReadFile (a zero-byte read might be sufficient) against the handle in order to signal it.
But it would probably be more sensible to hook WaitForSingleObject, check whether it is being called on the file handle in question, and if so modify the behaviour as appropriate.
My application checks for user input in its main thread:
while (running)
{
std::string console;
if (std::getline(std::cin, console))
{
process(&console);
}
}
Before that I have setup a sigaction to detect CTRL+C in conjunction with a function handler to shutdown other threads.
Now, when a SIGINT occurs the application crashes; GDB output:
I was looking around and found other solutions such as non-blocking input reading: (pseudo-code)
while (running)
{
if (input_avail())
{
getinput
process
}
else
sleep(1);
}
But even that fails for me at the sleep function (nanosleep):
So I'm quite curious on how other people achieve this?
(Using g++ v4.8.2 Kernel 3.10)
Additional info requested:
Before the main thread loop:
struct sigaction sigIntHandler;
sigIntHandler.sa_handler = signalinfo;
sigemptyset(&sigIntHandler.sa_mask);
sigIntHandler.sa_flags = 0;
sigaction(SIGTERM, &sigIntHandler, NULL);
sigaction(SIGQUIT, &sigIntHandler, NULL);
sigaction(SIGINT, &sigIntHandler, NULL);
Signal handler:
void signalinfo(int signum)
{
// Only setting a flag so threads know to exit.
pCore->Termination(signum);
}
Not sure if it answers your question, but the documentation of the XBoard protocol explains some common strategies how engine engine handle reading from stdin.
It basically sketches how you might implement your non-blocking pseudo code.
Source: XBoard protocol (6. Hints on input/output)
... on the input side, you are likely to want to poll during your search and stop it if new input has come in. If you implement pondering, you'll need this so that pondering stops when the user makes a move. You should also poll during normal thinking on your move, so that you can implement the "?" (move now) command, and so that you can respond promptly to a "result", "force", or "quit" command if xboard wants to end the game or terminate your engine. Buffered input makes polling more complicated -- when you poll, you must stop your search if there are either characters in the buffer or characters available from the underlying file descriptor.
The most direct way to fix this problem is to use unbuffered operating system calls to read (and poll) the underlying file descriptor directly. On Unix, use read(0, ...) to read from standard input, and use select() to poll it. See the man pages read(2) and select(2). (Don't follow the example of GNU Chess 4 and use the FIONREAD ioctl to poll for input. It is not very portable; that is, it does not exist on all versions of Unix, and is broken on some that do have it.) On Win32, you can use either the Unix-like _read(0, ...) or the native Win32 ReadFile() to read. Unfortunately, under Win32, the function to use for polling is different depending on whether the input device is a pipe, a console, or something else. (More Microsoft brain damage here -- did they never hear of device independence?) For pipes, you can use PeekNamedPipe to poll (even when the pipe is unnamed). For consoles, you can use GetNumberOfConsoleInputEvents. For sockets only, you can use select(). It might be possible to use WaitForSingleObject more generally, but I have not tried it. Some code to do these things can be found in Crafty's utility.c, but I don't guarantee that it's all correct or optimal.
A second way to fix the problem might be to ask your I/O library not to buffer on input. It should then be safe to poll the underlying file descriptor as described above. With C, you can try calling setbuf(stdin, NULL). However, I have never tried this. Also, there could be problems if you use scanf(), at least with certain patterns, because scanf() sometimes needs to read one extra character and "push it back" into the buffer; hence, there is a one-character pushback buffer even if you asked for stdio to be unbuffered. With C++, you can try cin.rdbuf()->setbuf(NULL, 0), but again, I have never tried this.
A third way to fix the problem is to check whether there are characters in the buffer whenever you poll. C I/O libraries generally do not provide any portable way to do this. Under C++, you can use cin.rdbuf()->in_avail(). This method has been reported to work with EXchess. Remember that if there are no characters in the buffer, you still have to poll the underlying file descriptor too, using the method described above.
A fourth way to fix the problem is to use a separate thread to read from stdin. This way works well if you are familiar with thread programming. This thread can be blocked waiting for input to come in at all times, while the main thread of your engine does its thinking. When input arrives, you have the thread put the input into a buffer and set a flag in a global variable. Your search routine then periodically tests the global variable to see if there is input to process, and stops if there is. WinBoard and my Win32 ports of ICC timestamp and FICS timeseal use threads to handle multiple input sources.
I'm writing a program that reads in a loop from the stdin, using the function fgets, as follows:
while(fgets(buffer2, BUFFERSIZE , stdin) != NULL){
//Some code
}
I want my code to be non-blocking, that is: I don't want the program to hold on the 'fgets' line when there's no input at the moment from the user.
How can i do it?
fgets() is a blocking function, it is meant to wait until data is available.
If you want to perform asynchronous I/O, you can use select(), poll(), or epoll(). And then perform a read from the file descriptor when there is data available.
These functions use the file descriptor of the FILE* handle, retrieved by:
int fd = fileno(f);
If you are using Unix or Linux, then one solution can be to mark the file descriptor used by the file to be non-blocking. Example:
#include <fcntl.h>
FILE *handle = popen("tail -f /als/als_test.txt", "r");
int fd = fileno(handle);
flags = fcntl(fd, F_GETFL, 0);
flags |= O_NONBLOCK;
fcntl(fd, F_SETFL, flags);
fgets should be non-blockng now and will return a null and set an error code for you.
If you have a proper POSIX environment, you can use select() or poll() to check for input on stdin's descriptor before calling fgets()... read().
Jan's comment below (thanks!) explains why you can't use fgets() with this approach... summarily, there's an extra layer of buffering in the FILE object, and data can already be waiting in though the select() finds nothing more on the file descriptor... preventing your program from responding in a timely way, and potentially hanging if some other system is waiting for a response to already sent data before sending more on stdin.
You basically have two options:
Run that loop in a separate thread.
Check if your OS supports some API for non-blocking IO.
This would sound a little like overkill, but this is the one, that comes to my mind.
Use 2 different threads - one using this loop and waiting blocking ( I don't think that this could be done non-blocking). And when something is read, push it into a pipe.
Meanwhile, the other thread will do whatever it needs to do and check for data in the pipe from time to time ( apparently, you want this to be asynchronous, or at least I get it this way. If so, this means different threads )
But then, you'll need to synchronize the two threads very well. You should check your OS about multithreading and IO operations.
On Linux, you can specify the end of input by pressing ctrl-d, and of-course you can do this using separate thread.
I was just wondering whether in C is it possible to peek in the input buffer or perform similar trickery to know whether a call to fgets would block at a later time.
Java allows to do something like that by calling BufferedReader.ready(), this way I can implement console input something like this:
while (on && in.ready()) {
line = in.readLine();
/* do something with line */
if (!in.ready())
Thread.sleep(100);
}
this allows an external thread to gracefully shutdown the input loop by setting on to false; I'd like to perform a similar implementation in C without resorting to non portable tricks, I already know I can make a "timed out fgets" under unix by resorting to signals or (better, even though requering to take care of buffering) reimplement it on top of recv/select, but I'd prefer something that would work on windows too.
TIA
Suggest to go with socket I/O routines,preferably poll() with required millisecond as timeout and eventually you can interpret timeout ( return value = -1 ) as unavailability of data in input buffer.
In my opinion,there is no non-blocking standard I/O function to achieve this functionality.
I'm not certain what are you talking about: a socket or a file handle?
For files there should be no blocking. The function returns immediately (besides of the I/O invocation itself).
For sockets - you may use the ioctlsocket function:
The following tells if there's a rcv data pending:
ULONG nSize;
ioctlsocket(sock, FIONREAD, &nSize);
The following transfers the socket into non-blocking mode:
ULONG nEnable = 1;
ioctlsocket(sock, FIONBIO, &nEnable);
When in Non-blocking mode - functions on socket never block. If they can't fulfill the request they return an error, and the error code is WSAEWOULDBLOCK
Plus, on Windows there're dozens of much more efficient methods. Those are:
Using Overlapped I/O. This is non-trivial, but gives superior performance
Associating socket with a waitable event. This transfers the socket to a non-blocking mode, plus the specified event is signaled when a network event occurs.
Associate it with the window handle. This is convenient for UI-oriented programs.