Use pselect instead of self-pipe

[egmontkob]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

current git (post-4.8.33)

Operating system

all

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

Forking from #4071:

Now that we use pselect() in our code, we could replace the self-pipe SIGWINCH reporting with proper use of pselect().

pselect() is POSIX since 2001, and implemented atomically in Linux in 2006.

The self-pipe trick is a well known workaround for systems that don't support an atomic, race-condition-free way of waiting for either a file descriptor activity or a signal. This is the exact problem pselect() was designed to solve in a clean way, obsoleting the need for the self-pipe trick.

Expected behavior

.

Actual behavior

.

Additional context

No response

[ossilator]

and to fork my objection as well: i don't think that's a particularly good idea. we check that flag in quite some places. even if the check itself is centralized (i think it is), it's still a lot of extra syscalls.

another concern: glib has rather advanced handling for signals, so this probably wouldn't fundamentally impair a later migration to the glib main loop. but it would be probably easier to verify correctness if everything was serialized into fd events.

[egmontkob]

Take my feature request as "let's see if it's worth doing" rather than "let's do it".

I have not yet studied how much work this would take, what would need to be done.

My standard idea is that a program sits in its main select() call, waiting for data through one of its fds, including the self-pipe one. This would be replaced by a pselect(), equal number of syscalls. The signal handler method would ideally only flip a boolean and do nothing more.

Now, it might surely happen, especially for mc, that longer operations (let's say copying large files) don't return control to the main loop. Rather, they every once in a whlie during their operation check whether sigwinch has arrived, and if so then act on it.

I don't know off the top of my head what we do in order to generate a reasonable amount of UI updates. Updating the UI too frequently is a waste of resources (involving among others, again, syscalls). Updating the UI too rarely results in a poor user experience. Do we have something time-based there? If so, i.e. if we have something that sends updates approximately 60 times a second, we could hook up the sigwinch check there – an extra syscall 60 times per second is nothing to worry about.

Performing some task with a certain rough frequency is pretty cheap, (at least on Linux) gettimeofday() has some vdso hack that it's not a real syscall, it doesn't switch to kernel context and is thus blazingly fast.

If we don't have anything like this, and we'd just issue pselect() calls with zero timeout to check for a pending sigwinch too often then it could really impose an unwanted load – but then chances are that our UI updating logic already wastes too much resources then.

I really don't know if this is the case, we'd have to study mc's code.

By the way, for long-lasting operations, you could just unblock sigwinch at the beginning and block at the end. In between you could still resort to checking that volatile bool and if set then handle the winch.

So, your concerns definitely have solid grounds, we'll need to study mc to understand if these would really become a problem or not – or, in fact, whether the change is worth all the work.