Use read() C function without stopping code

Question

I'm trying to read data from a joystick using C code. I have found online the way to do it.

This solution seems to work fine but with a problem. When the code reachers the the read() function, it stops and waits until there is change in the joystick device:

int read_event(int fd, struct js_event *event)
{
    ssize_t bytes;

    bytes = read(fd, event, sizeof(*event));
    if (bytes == sizeof(*event))
        return 0;
    return -1;
}

I'm trying to find a way to make the code run continously and if there is no change in the control device, just return the previous state. So far I did not succeed. Maybe someone can help.

2 options - [select(2)](http://man7.org/linux/man-pages/man2/select.2.html) or threads. — Ajay Brahmakshatriya, Aug 04 '17 at 14:38
@EugeneSh. I have opened it with: device = "/dev/input/js0"; js = open(device, O_RDONLY); as in the original link. — Janus Gowda, Aug 04 '17 at 14:43
The function you present looks like it may assume that the file associated with file descriptor `fd` is in non-blocking mode. — John Bollinger, Aug 04 '17 at 14:43
@AjayBrahmakshatriya, I would prefer the most simple solution without threads or anything. I guess there must be a way of doing it. Is it normal that read() waits? — Janus Gowda, Aug 04 '17 at 14:43
@JanusGowda it is normal that `read()` blocks until it can transfer at least one byte, *except* for files that are open in non-blocking mode. You should be able to open the device in non-blocking mode by including the flag `O_NONBLOCK` in the options bitmask you pass to `open()`. — John Bollinger, Aug 04 '17 at 14:45
@JanusGowda yes, read waits until data is available to be read. — Ajay Brahmakshatriya, Aug 04 '17 at 14:46
@JohnBollinger Thanks! This worked great. If you want to put it in an answer I give you the credit. — Janus Gowda, Aug 04 '17 at 14:52
I don't know what you need this behavior for, but did you consider to create an event input thread? Like this you could divide the logic for things that you need to be continuously running from that logic where e.g. there may be a block waiting for user-input. — Jan, Aug 04 '17 at 15:15

score 2 · Accepted Answer · answered Aug 04 '17 at 15:02

Given that you are opening the joystick device via open() and reading from it via read(), I infer that you are coding for a machine that implements a POSIX interface. For most files, the POSIX read() function blocks until it can transfer at least one byte, and that is indeed the behavior you observe.

One way to avoid that is to open the file in non-blocking mode, or to put it in non-blocking mode after opening it but before reading it. You can do the former by adding the O_NONBLOCK flag to your open options:

 js = open(device, O_RDONLY | O_NONBLOCK);

That should interact cleanly and favorably with your existing code for reading joystick events. In the case that no event is available to read, your read() call should return immediately, with return value -1, and errno set to EAGAIN. Otherwise, it will return the number of bytes transferred.

Note that in general, read() is not guaranteed to transfer the full number of bytes you request -- it may successfully read fewer, which you can determine from its return value, and if you don't account for that then you can come to grief. I don't think you'll see any short reads from the joystick device, however; you should get either a complete event or nothing.

score 0 · Answer 2 · answered Aug 04 '17 at 14:43

0

I'm not sure about the actual API (system call) function, but my idea should work.

Use something like GetNumberOfInputEvents (a WinAPI function) to determine whether your read will get stuck (with nothing to read). Then if you judge that it'll get stuck, skip it.

See Checking the stdin buffer if it's empty for more information.

Pseudo code:

read_event(Event* event){
    if (is_event_buffer_empty())
        // Do nothing because `read` is stuck
    else
        SystemAPI_ReadEvent(event);
}

answered Aug 04 '17 at 14:43

iBug

35,554
7
89
134

1

This is very wrong. Because data might become unavailable after the `is_event_buffer_empy()` - Some other thread reading it. – Ajay Brahmakshatriya Aug 04 '17 at 14:47
3

The OP is reading via a file descriptor, not a stream, so there is no stream buffer (unless he implements one himself). Even if there were, the buffer being empty is not the same thing as there being no data available to read. – John Bollinger Aug 04 '17 at 14:48

Use read() C function without stopping code

2 Answers2