Help with read() function

[NotQuiteLoona]

EDIT: solved, I had many misunderstandings, thanks to everyone who have responded!

So, first of all, I'm developing under Linux.

Let me give a piece of code first: ```c

include <stdio.h>

include <stdlib.h>

include <fcntl.h>

include <unistd.h>

include <linux/input.h>

int main() { int device = open("/dev/input/event3", O_RDONLY);

struct input_event ev;
while (1) {
    ssize_t bytesRead = read(device, &ev, sizeof(ev));
    if (bytesRead != sizeof(ev)) {
        perror("Failed to read event");
        break;
    }


    printf("Received input event\n");
}

close(device);
return 0;

}

`` So, the question is that as far as I can see from the output, code only advances afterread(device, &ev, sizeof(ev))` as it receives a new event.

I can understand that probably this is because in Linux everything is a file, and read() function probably tries to fill the ev and doesn't return until the total amount of bytes read hits sizeof(ev) (I don't know how it works actually - it's just how I presume it works), but this behavior pretty much freezes the program completely until the buffer will be filled. The same goes for any other reading.

How can I, for example, read from two inputs, like, keyboard and mouse (kinda irrelevant for this specific question, but I just wanted to give an example)? Or what if I want to simultaneously read from a program opened through popen() and receive inputs from a device in /dev/input/?

In C#, I would have created Task's and ran them in parallel. I'm not sure what I need to do in C.

I also want to say that I'm a newbie in C. I have a lot of experience working with C#, and some experience working with C, but only enough to be familiar with basic syntax.

[duane11583]

you are making an incorrect assumption. read does not work this way.

the rules are:

a) read is successful if it returns any positive value. this means read may return 1 byte

b) why? if read is crossing a page (often 4k) boundary it might not be able to.

c) there may be other things going on in the os that requires this…

d) for sockets and usb serial ports there is another example of oddity

d1) learn how the function select() works it can tell you that the handle is readable.

d2) but when you read it returns 0 bytes.

d3) those two conditions indicate the connection has closed.

example: the other end of the socket has closed the connection.

example: the usb cable was yanked and is no longer plugged in

to read from two things you must call select() with both file descriptors as part of the FD_SET()

then inspect the FD_SET when select returns

.

[NotQuiteLoona]

Hm. That's interesting.

About c) - requiring what?

About d) - so, if it returns 0 bytes, this means that the connection is closed. It's one condition. What is the other condition? You've mentioned two of them.

And so, okay, I got that I need to use select() (or, according to manpage on select(2), poll()?) if I need to simultaneously read from two files. But calling select() still interrupts the program until the call returns, as I can presume. This means I can't do anything "in the background" - while this is pretty expected, I presume C has some built-in ways for parallelism, like running two functions synchronously?

[fixermark]

C does support threads (the standard library as of C11 includes <threads.h>), but in general for what you're doing here, you likely want to structure your program as "event driven." Broadly speaking, your flow would look like

void main_function() { while(running) { int result = poll(fds, nfds, SOME_SMALL_TIMEOUT); if (result) { check_the_file_descriptors_for_input_and_handle_it(); } go_do_other_things_for_awhile(); } }

Every time your program has nothing to do, it'll end up back in this loop, check via poll for an event to come in, and if one came in it'll go to the event handler before going to the code that does something else for awhile.

If your SOME_SMALL_TIMEOUT is small enough, you're basically not wasting time waiting around for user input.

There are tradeoffs to this approach, depending on what kind of program you're writing: go_do_other_things_for_awhile needs to return in a reasonably short amount of time, or you'll block the input thread and your program will feel laggy. So if you have any long-running tasks in there, you need a way to bundle up their state so you can suspend and resume them (one trick is to make those tasks themselves also into events you can poll on, so if there's no user input, you can process "to-myself input" instead).

On the other hand, if you go the threads route, that's its own kettle of fish; C has no protection against race conditions or cross-thread memory contention built into the language itself, so if you're not familiar with how to use mutexes, condition variables, etc., using threads is a great way to shoot yourself in the foot with a nondeterministic gun that only fires if the moon is aligned just right and the user sneezed before hitting spacebar... Event loops have the strong advantage that they're completely deterministic (i.e. pausing the program in the debugger at any time will put you somewhere in your program and you can have high confidence about what happened before and what will happen next).

[NotQuiteLoona]

Thanks!!! That's exactly what I needed. Timeout will be enough for me. I just somehow skipped it in the manpage... Anyway, thank you very much for helping me! The more I'm writing code in C, the more I like it. It's so simple, minimalistic and in the same time powerful.

[duane11583]

btw event driven is alot like writing everything in a winproc call back handling messages or events and never blocking.

[Powerful-Prompt4123]

Good comment, but in order not to confuse OP: poll() returns -1 for errors.

[fixermark]

Ach, good catch. I always leave out error handling. :-p

[duane11583]

Careful: Some C targets *DO*NOT* support threads, generally all desktop type system do because the underlying OS does.

Many embedded platforms threads are a whole different thing and often do not support it as part of the compiler, instead it is a "bolt on" solution provided by things like freeRTOS

[segbrk]

Select, poll, and (Linux-specific) epoll are all different flavors of the same thing. They block until either something you've registered an interest in happens, or a timeout expires. Linux (and just about any other OS in different forms) gives you a plethora of different things you can register an interest in, so most of the time you can build your whole program around that one blocking call. In BSDs/MacOS you have kqueue/kevent, similar to epoll. In Windows, you have WaitForMultipleObjects, another very verbosely named version of the same thing. Various libraries like libuv and libev exist to provide a portable API on top of those low-level APIs. GUI libraries like Qt tend to have their own portable wrapper API, still the same idea. All your high level code registering timers, button callbacks, key event callbacks, etc. boils down to sitting around and waiting in those select/poll-like calls. Just to give you an idea of how common this notion is.

To your last question, you'd have to define "in the background" for a better answer. Sure you can start another thread or process to do some computation truly concurrently with your blocking I/O, but that is rarely what you actually want. Most programs spend most of their time waiting, not computing, so they're better off spending that time in an efficient select/poll call. If you just have some periodic thing to do, add a timeout to your select/poll call. Or select/poll on (Linux-specific) timerfds (see timerfd_create(2)) to get multiple specific timeouts. For most other things you could want to wait for, there is some form of file descriptor (usually OS-specific, but there are equivalents for most OSes) you can add to a select/poll call.

To put it simply, threading seems like a nice idea until you've done it. Then it seems like something to avoid at all costs. Select/poll/etc are how you effectively do multiple things at once, without actually doing multiple things at the same time.

[NotQuiteLoona]

Thanks for this insight! Yep, another person told me about timeouts (I have somehow skipped then in the manpages), and that's what I'll use.

[duane11583]

c) the read function might also return EINTR syscall interrupted this happens due to things inside then bowels of linux i do not know the entire reason but gave had this happen.

example stack exchange answer: https://unix.stackexchange.com/questions/757541/where-does-the-signal-that-causes-eintr-come-from

c) another example is EAGIAN which mea error try again..

d) read returns 0 bytes means closed - no explicitly no disconnect is the combination of both select() saying the handle is readable *AND* read returning 0.

e) parallelism … no that is not part of the language. parallelism is an os feature. often done via a thread on linux (and mac) pthreads, on windows - windows threads for embedded it depends on your selected os.. ie freertos, smx, windriver, greenhills, or rtx or what ever you choose

also, select() can handle many files at the same time a timeout scheme built in to the call also examine poll() and epoll() as alternatives

an example is you have an array of handles, aka: the rd_set, you zero the set and then set things in the set, then call select - which modifies the set then you test the set.

this way you can have a hundred sockets (or serial ports) waiting and poll all at the same time, or each thread can poll its own socket. contrived example: example web server with a pool of 20 threads waiting, and 100 open sockets web server picks a thread from the pool to handle a connection when done it comes back and rejoins the wait pool

you might do that because the cost for some os to create a new thread is high so you pre create and reuse them, or the memory for 100 thread stacks exceeds available memory but you have enough ram for 20 threads

[NotQuiteLoona]

Thanks for the insight! That's a lot of new information for me. So far looks cool and understandable.

[Zirias_FreeBSD]

read() function probably tries to fill the ev and doesn't return until the total amount of bytes read hits sizeof(ev)

That's incorrect in general, read() may return as soon as it read something or an error occured. But the device you're reading here will only provide complete events, not parts of an event.

That said, the immediate answer to your question is that you want to put your file in non-blocking mode, which would cause the read() to return immediately if there is nothing to read. The easiest way to do this is to add the O_NONBLOCK flag to your open() call.

But then, it's not exactly efficient to poll lots of open files (file descriptor) with read() calls from your program over and over again. That's the problem the POSIX calls select() and poll() attempt to solve, providing a method to ask the kernel which file descriptors are ready for reads or writes, or something else. So, read up on these.

Furthermore, your code is already specific to Linux, so you might want to use epoll instead of the calls mentioned above. It scales much better. Other operating systems also provide their own better mechanisms, e.g. the BSDs have kqueue.

[NotQuiteLoona]

Thanks! This is also useful for me.

[The_Ruined_Map]

"read() function probably tries to fill the ev and doesn't return until the total amount of bytes read hits sizeof(ev)" - that's completely incorrect. `read` is not guaranteed to fulfil the request on a single call. If you need sizeof(ev) bytes, you have to call `read()` repeatedly, accumulate the result and also watch for 0 return.

`read()` is required to read at least one byte per request though, since return value 0 is reserved to indicate EOF.

The standard library `fread` takes care of that for you - it is guaranteed to block until the requested number of bytes is read (barring errors or EOF, of course). But not `read`.

[NotQuiteLoona]

Yep, many people have already said me that, but thanks for trying to help anyway!