0

I understand how hardware interrupts work. I have a basic question about I/O, and will use keyboard and characters from key presses as the context for the question.

In a general sense, do processes tend to use polling (the process polling the kernel) or signals (the kernel notifying the process) to access characters from a buffer in the kernel where they have been stored temporarily?

I understand how polling can be done with a simple loop.

As an even more specific example, when I type this question, is the browser polling the kernel (and, the polling is active while I have clicked in the text field), or, is the kernel using a signal and triggering a signal handler in the process managing this browser window text input field?

Improve this question
1
  • "In a general sense, do processes tend to use polling (the process polling the kernel) or signals .." -- Neither. Preferred method in a multitasking OS is for a process to use blocking syscalls (e.g. I/O request). This lets the kernel efficiently handle syscalls with internal events, rather than the process burdening the kernel & system with the (less efficient) schemes you mention.
    – sawdust
    Commented Jan 20, 2023 at 9:50

1 Answer 1

Reset to default
1

It really depends on the OS, but as far as I know, both Windows and all Unix-like systems primarily use polling (i.e. the kind of polling where the process sleeps waiting for a blocking system call to return – not the kind of polling where the process keeps checking repeatedly). Signal usage is rare.

  • In the most basic case, if the process wants to read synchronously from a single file handle, it will call read() or ReadFile() and the system call will block until data is available. (It might create several threads, each waiting for read() on a different file handle, but that's uncommon.)

  • With multiple sources, the process would call poll() or WaitForMultipleObjects(), which also blocks until some event and eventually returns one of the given file handles which the process could read() from.

    When dealing with a large amount of sources, epoll or kqueue are preferred – I am not sure of the Windows equivalent; it might be IOCP or Overlapped I/O. (See also: the new io_uring API on Linux and the almost identical IoRing on Windows.)

Most larger programs are structured around a central "event loop" which will poll() on all sources, handle some events, then poll() again, repeat. For example, when you're using a web browser on Linux, two programs are involved:

  1. the display server (such as Xorg for X11 or GNOME Shell for Wayland) has an event loop that polls for user input via /dev/input/* devices (from kernel) as well as application X11 or Wayland events via sockets (draw commands from graphical apps);

  2. the browser has an event loop that polls for user input via its X11 or Wayland socket (from the display server) as well as network traffic from open sockets (e.g. active HTTP downloads).

There exist a few old "asynchronous I/O" APIs do use signals (the one from 4.2BSD, I believe?); setting the FASYNC flag will cause SIGIO to be sent; but overall it seems to be very rare. (And if a process is doing nothing but waiting to receive a signal, then it might as well just wait for a blocking poll() to return instead, without any of the hassle of signal handlers – especially without worrying about reentrancy or overflowing the signal queue...)

In fact, on Linux and FreeBSD, event-loop frameworks often choose to receive signals via polling – the program masks all signals from their normal delivery, then uses signalfd() to create a file handle that can be polled, and when a signal occurs a struct siginfo can be read from the signalfd handle at the process' own leisure (the event loop is responsible for calling the signal handler). Similarly, timer events can be delivered through timerfd without relying on SIGALRM and such.

Improve this answer
12
  • "the kind of polling where the process sleeps waiting for a blocking system call to return" -- That's not "polling" at all, but rather event-driven. The event/signal is all handled by/within the kernel. So the OP's expectation of "the kernel notifying the process" is concealed by the API when it simply returns from the blocking syscall. The actual results (e.g. latency and CPU efficiency) are essentially the same to the OP's definition of "signal" rather than the OP's definition of "poll".
    – sawdust
    Commented Jan 20, 2023 at 9:27
  • thank you both. I agree with @sawdust that the blocking syscall is similar to my assumption of what "signal" would do. I don't have the terminology for this yet, but both of you have helped me with some terms now so I have a bit more to go on. it will take me a little while to digest it all.
    – BipedalJoe
    Commented Jan 20, 2023 at 10:44
  • would I be correct in that even a blocking syscall "read()" would itself often be in a loop in a process, but, the process would "halt" (with the blocking syscall) until the kernel receives at least one character from keyboard, but then when control returns to process it just continues the loop one more iteration, making another blocking syscall "read()"? (and even if read() is not character-by-character, it still seems like a loop would be used in the process if waiting to read more things, like on a socket. )
    – BipedalJoe
    Commented Jan 20, 2023 at 10:45
  • @sawdust: It's still called "polling" much too often. One difference is that with poll() control returns to where the process initially called it (i.e. the process has to actively request the notification), while signals are delivered out-of-band and interrupt the regular flow (i.e. they're more or less unsolicited). So no, I wouldn't say it's the same definition at all.
    – grawity_u1686
    Commented Jan 20, 2023 at 11:03
  • if it receives input event structs or characters or not is good to know but not really what I asked. what I asked is, is the blocking syscall running all the time and returning all key presses, or does the process "refresh" the blocking syscall by issuing a new one each time the action of the previous one returns (thus using a loop maybe. )
    – BipedalJoe
    Commented Jan 20, 2023 at 11:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .