From Newsgroup: comp.os.linux.misc

(Given I'm commenting on the content of the online manual on a Linux
system, I'm adding and followingup-to comp.os.linux.misc.)

On 2026-08-11, Lawrence DrCOOliveiro wrote:

On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:

For select (called unix-fast-select in SBCL), see sb-unix.

select(2) is considered an archaic way of doing things these days,
because of its ABI limitations. The modern way is poll() <https://manpages.debian.org/poll(2)> (POSIX) or even epoll() <https://manpages.debian.org/epoll(7)> (Linux-specific).

The online manual here (a GNU/Linux system) says:

"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,
but that description with "*A* file descriptor" does make it sound like
poll is not a suitable replacement for select.
--
Nuno Silva

(Not subscribed to comp.lang.c)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

Nuno Silva wrote:

The online manual here (a GNU/Linux system) says:

"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,
but that description with "*A* file descriptor" does make it sound like
poll is not a suitable replacement for select.

The POSIX/SUS poll() page has:

"poll, ppoll - input/output multiplexing"

https://pubs.opengroup.org/onlinepubs/9799919799/functions/poll.html
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

Nuno Silva <nunojsilva@invalid.invalid> writes:

(Given I'm commenting on the content of the online manual on a Linux
system, I'm adding and followingup-to comp.os.linux.misc.)

On 2026-08-11, Lawrence DrCOOliveiro wrote:

On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:

For select (called unix-fast-select in SBCL), see sb-unix.

select(2) is considered an archaic way of doing things these days,
because of its ABI limitations. The modern way is poll()
<https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
<https://manpages.debian.org/epoll(7)> (Linux-specific).

The online manual here (a GNU/Linux system) says:

"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,

Perhaps you'd be better off consulting the definitive
manual page for poll/ppoll.

https://pubs.opengroup.org/onlinepubs/9799919799/functions/ppoll.html

NAME

poll, ppoll - input/output multiplexing

SYNOPSIS

#include <poll.h>

int poll(struct pollfd fds[], nfds_t nfds, int timeout);
int ppoll(struct pollfd fds[], nfds_t nfds,
const struct timespec *restrict timeout,
const sigset_t *restrict sigmask);
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Fri, 14 Aug 2026 13:53:21 +0100, Geoff Clare wrote:

Nuno Silva wrote:

The online manual here (a GNU/Linux system) says:

"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not
singular, but that description with "*A* file descriptor" does make
it sound like poll is not a suitable replacement for select.

Oh, it most certainly is. And then some.

The POSIX/SUS poll() page has:

"poll, ppoll - input/output multiplexing"

https://pubs.opengroup.org/onlinepubs/9799919799/functions/poll.html

That is the official reference. But perhaps slightly more readable,
and with examples: <https://manpages.debian.org/poll(2)>.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 8/14/26 07:26, Nuno Silva wrote:

(Given I'm commenting on the content of the online manual on a Linux
system, I'm adding and followingup-to comp.os.linux.misc.)

On 2026-08-11, Lawrence DrCOOliveiro wrote:

On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:

For select (called unix-fast-select in SBCL), see sb-unix.

select(2) is considered an archaic way of doing things these days,
because of its ABI limitations. The modern way is poll()
<https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
<https://manpages.debian.org/epoll(7)> (Linux-specific).

The online manual here (a GNU/Linux system) says:

"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,
but that description with "*A* file descriptor" does make it sound like
poll is not a suitable replacement for select.

Polling, for this sort of thing, has to be
fast and constant - a big CPU drag. You are
basically WAITING for something to happen -
which MAY or may NOT happen at any moment.

The writers of various utils and basic system
functions NEED to include some kind of easy
flag or interrupt routine that other utils can
monitor at VERY LOW CPU/Time investment.

Coding such 'trigger indicators' is NOT difficult.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Fri, 14 Aug 2026 23:47:19 -0400, c186282 wrote:

Polling, for this sort of thing, has to be
fast and constant - a big CPU drag. You are
basically WAITING for something to happen -
which MAY or may NOT happen at any moment.

I used select() rather than poll() but I'm archaic. Typically the select
call was in the main loop. The timeout was often 1 second. If the call returned a ready fd you took care of business. If it timed out, then you
did whatever housekeeping was necessary, making sure it wasn't a long
process.

Without the select the main loop would chew up 100% of the CPU. Interrupt
have their place but often complex ISRs are used that aren't any faster
than polling.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 15/08/2026 08:20, rbowman wrote:

On Fri, 14 Aug 2026 23:47:19 -0400, c186282 wrote:

Polling, for this sort of thing, has to be
fast and constant - a big CPU drag. You are
basically WAITING for something to happen -
which MAY or may NOT happen at any moment.

I used select() rather than poll() but I'm archaic. Typically the select
call was in the main loop. The timeout was often 1 second. If the call returned a ready fd you took care of business. If it timed out, then you
did whatever housekeeping was necessary, making sure it wasn't a long process.

Without the select the main loop would chew up 100% of the CPU. Interrupt have their place but often complex ISRs are used that aren't any faster
than polling.

Select probaby uses an ISR
--
Renewable energy: Expensive solutions that don't work to a problem that doesn't exist instituted by self legalising protection rackets that
don't protect, masquerading as public servants who don't serve the public.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-08-15, c186282 <c186282@nnada.net> wrote:

On 8/14/26 07:26, Nuno Silva wrote:

(Given I'm commenting on the content of the online manual on a Linux
system, I'm adding and followingup-to comp.os.linux.misc.)

On 2026-08-11, Lawrence D???Oliveiro wrote:

On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:

For select (called unix-fast-select in SBCL), see sb-unix.

select(2) is considered an archaic way of doing things these days,
because of its ABI limitations. The modern way is poll()
<https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
<https://manpages.debian.org/epoll(7)> (Linux-specific).

The online manual here (a GNU/Linux system) says:

"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,
but that description with "*A* file descriptor" does make it sound like
poll is not a suitable replacement for select.

Polling, for this sort of thing, has to be
fast and constant - a big CPU drag. You are
basically WAITING for something to happen -
which MAY or may NOT happen at any moment.

Despite the names, these functions WAIT for events.
Yes it could be sort of confusing.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 15/08/2026 12:07, Jim Jackson wrote:

On 2026-08-15, c186282 <c186282@nnada.net> wrote:

On 8/14/26 07:26, Nuno Silva wrote:

(Given I'm commenting on the content of the online manual on a Linux
system, I'm adding and followingup-to comp.os.linux.misc.)

On 2026-08-11, Lawrence D???Oliveiro wrote:

On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:

For select (called unix-fast-select in SBCL), see sb-unix.

select(2) is considered an archaic way of doing things these days,
because of its ABI limitations. The modern way is poll()
<https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
<https://manpages.debian.org/epoll(7)> (Linux-specific).

The online manual here (a GNU/Linux system) says:

"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,
but that description with "*A* file descriptor" does make it sound like
poll is not a suitable replacement for select.

Polling, for this sort of thing, has to be
fast and constant - a big CPU drag. You are
basically WAITING for something to happen -
which MAY or may NOT happen at any moment.

Despite the names, these functions WAIT for events.
Yes it could be sort of confusing.

Normal mechanism would be to put the calling thread into suspense, and
trigger a resume by setting a flag from interrupt. The thread then
'resumes' and checks to see why it was woken up.

AFAICT from a cursory glance there is no difference between select and
poll 'under the hood'.

They just present themselves differently
--
Civilization exists by geological consent, subject to change without notice.
rCo Will Durant

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

c186282 <c186282@nnada.net> writes:

On 8/14/26 07:26, Nuno Silva wrote:

The online manual here (a GNU/Linux system) says:
"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,
but that description with "*A* file descriptor" does make it sound
like poll is not a suitable replacement for select.

https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING

Polling, for this sort of thing, has to be
fast and constant - a big CPU drag.

poll() doesnrCOt poll, despite the name.

You are basically WAITING for something to happen - which MAY or may
NOT happen at any moment.

The writers of various utils and basic system functions NEED to
include some kind of easy flag or interrupt routine that other utils
can monitor at VERY LOW CPU/Time investment.

Already done, several decades ago.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 8/15/26 03:20, rbowman wrote:

On Fri, 14 Aug 2026 23:47:19 -0400, c186282 wrote:

Polling, for this sort of thing, has to be
fast and constant - a big CPU drag. You are
basically WAITING for something to happen -
which MAY or may NOT happen at any moment.

I used select() rather than poll() but I'm archaic. Typically the select
call was in the main loop. The timeout was often 1 second. If the call returned a ready fd you took care of business. If it timed out, then you
did whatever housekeeping was necessary, making sure it wasn't a long process.

Without the select the main loop would chew up 100% of the CPU. Interrupt have their place but often complex ISRs are used that aren't any faster
than polling.

Any kind of ISR is almost always the best
solution to the described sort of need.
Polling is CRUDE and, as we both said, eats
CPU like mad.

Having done stuff with a lot of micro-controllers,
which don't have much CPU to spare anyway, always
did ISRs whenever possible to get data from devices.
Depending, the ISR can push events onto a sort of
list/stack and then you can deal with them kinda
all at once every x-often.

Alas, the younger set ASSUMES kinda infinite
CPU/mem. It's poor thinking, poor discipline.
IMHO, "Intro To Programming" should always
start with like PICs or basic Ards. Let 'em
learn to get the most done with the least
resource consumption. Sometimes requires being
CLEVER and/or learning weird quirks of the
hardware. But we NEED clever programmers !!!

Tax calculations, almost any idiot can code an
app. Next mission to Mars or Titan, we need
REALLY damned clever humans. "AI" can be kinda
good, but it's not really "clever" and does
not seem to anticipate weird fails.

Still wish we'd find satellite/space-probe
software gurus in these groups. The hyper-
durable/redundant systems they do are nearly
black magic. How DO you cope when cosmic rays
may flip bits anywhere anytime ? When some
important chip FAILS entirely ? The hardware
folks are fantastic as well ... remote
reload/redo/reboot of the whole system on some
3rd-tier backup mem chip ...

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 8/15/26 07:20, Richard Kettlewell wrote:

c186282 <c186282@nnada.net> writes:

On 8/14/26 07:26, Nuno Silva wrote:

The online manual here (a GNU/Linux system) says:
"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,
but that description with "*A* file descriptor" does make it sound
like poll is not a suitable replacement for select.

https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING

Polling, for this sort of thing, has to be
fast and constant - a big CPU drag.

poll() doesnrCOt poll, despite the name.

Then it should be re-named.

You are basically WAITING for something to happen - which MAY or may
NOT happen at any moment.

The writers of various utils and basic system functions NEED to
include some kind of easy flag or interrupt routine that other utils
can monitor at VERY LOW CPU/Time investment.

Already done, several decades ago.

I know, I was there, in the middle of it.

"Chips" were the NEW NEAT-O Things. Didn't
need a giant refrigerated box full of of
big boards full of discrete transistors.
Been there, seen those. You brought a
jacket so you could do shit in the CPU
room. Remember a DEC unit at one place,
a roughly 1.5 meter square box in the
middle of the laser-leveled cold-ass
room PACKED with discrete transistors.
The TAPE units lined the walls. Everything
was 'overlay code' approach, explicit or
implied.

They COULD run an office full of serial
terminals though, get lots or Real Stuff
DONE ....

FORTRAN and COBOL.

DID miss the 'tube era' - 'programming' with
jumper wires - thank the gods. Hail Woden !

Anyway, I/O Events, they SHOULD trigger a ISR
that, at minimum, sets a "smart flag". Other
software can LOOK for and ACT on those flags
or lists or stacks WHEN MOST CONVENIENT.

I remember when CPUs were CRAP ... slow, very
limited. This stuck with me. ALWAYS look for
the lowest CPU/Mem equation for dealing with
"events".

If anyone wants to learn good programming, start
them on micro-controllers - near ZERO resources.

Hmmmmm ... any source for late 50s "drum drives" ?
It'd be just COOL to make 'em work with today's
devices ! :-)

Knew a guy who once worked with the inventor of
the 'disk drive'. Seems the original protos used
a coat of pure cobalt as the magnetic medium. Not
really ideal, but they couldn't make ferrous
coatings smooth/flat enough at the time.

(Hmm ... legend says that Gods still live so long
as they're remembered, their names still spoken.
So, did I just revive Woden ? Granny pronounced
it very close to "Wooden")

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-08-16 04:41, c186282 wrote:

-a Tax calculations, almost any idiot can code an
-a app.

I object to that. I do not want an idiot telling how much tax to pay.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

c186282 <c186282@nnada.net> writes:

Richard Kettlewell wrote:

c186282 <c186282@nnada.net> writes:

On 8/14/26 07:26, Nuno Silva wrote:

The online manual here (a GNU/Linux system) says:
"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,
but that description with "*A* file descriptor" does make it sound
like poll is not a suitable replacement for select.

https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING

Polling, for this sort of thing, has to be
fast and constant - a big CPU drag.

poll() doesnrCOt poll, despite the name.

Then it should be re-named.

Obviously thatrCOs not happening. And what would be the point? Make life
easier for people who react to single words without reading any
documentation?
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 16/08/2026 09:59, Richard Kettlewell wrote:

c186282 <c186282@nnada.net> writes:

poll() doesnrCOt poll, despite the name.

Then it should be re-named.

Obviously thatrCOs not happening. And what would be the point? Make life easier for people who react to single words without reading any documentation?

Of course. Otherwise they might elect Trump as a president...
--
The difference bweteen a psychopath and a saint is that the psychpoath
takes what he can and gives only what he must, but the saint gives
everything he can and takes only what he needs.



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Sun, 16 Aug 2026 10:50:30 +0200, Carlos E. R. wrote:

On 2026-08-16 04:41, c186282 wrote:

-a Tax calculations, almost any idiot can code an app.

I object to that. I do not want an idiot telling how much tax to pay.

My wife volunteered to do our Federal taxes one year. She's far from an
idiot and has more degrees than I, unfortunately not in the STEM area. I'm glad I checked her work. I don't know about yours but our tax forms are designed to keep H.R. Block in business

if (line45 < .35 * line22 && dependants > 3) {
goto line71;
}
else if (line45 > 32196) {
your_screwed();
}
else {
fill_out_form_1040XYZ();
}

They don't mail out printed forms anymore but it used to be a rather thick booklet.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Sun, 16 Aug 2026 02:09:57 -0400, c186282 wrote:

You brought a
jacket so you could do shit in the CPU room.

At RPI the shrine where the 360/30 lived was the only place on campus with A/C. Not a bad thing on those days when the humidity in the Hudson Valley
hits 99.9%.

The last place I worked was a converted mill building. Rather nice architecturally but every HVAC company in town had taken a shot at it with limited success. Programming wore flannel shirts in August and it wasn't a style thing. Portable electric heaters appeared to the consternation of
the maintenance people.

Conversely, I leaned toward short sleeved shirts in December. The poor bastards on the 2nd floor were on the opposite schedule.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 8/16/26 06:42, The Natural Philosopher wrote:

On 16/08/2026 09:59, Richard Kettlewell wrote:

c186282 <c186282@nnada.net> writes:

poll() doesnrCOt poll, despite the name.

-a-a Then it should be re-named.

Obviously thatrCOs not happening. And what would be the point? Make life
easier for people who react to single words without reading any
documentation?

Of course. Otherwise they might elect Trump as a president...

Listen to the "socialists" - I'd elect Trump
over and over until he's 125 years old rather
than have THOSE shits in charge of anything.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 8/16/26 15:13, rbowman wrote:

On Sun, 16 Aug 2026 02:09:57 -0400, c186282 wrote:

You brought a
jacket so you could do shit in the CPU room.

At RPI the shrine where the 360/30 lived was the only place on campus with A/C. Not a bad thing on those days when the humidity in the Hudson Valley hits 99.9%.

Heh heh ... yea, there WAS a little span where
the coolest place in town, literally, was the
govt/biz CPU room !

The last place I worked was a converted mill building. Rather nice architecturally but every HVAC company in town had taken a shot at it with limited success. Programming wore flannel shirts in August and it wasn't a style thing. Portable electric heaters appeared to the consternation of
the maintenance people.

Older buildings, like old British castles, were NOT
designed with modern conveniences in mind. The Brits
just ran lots of pipes and shit along the upper walls.
Kinda ugly, but WORK.

Conversely, I leaned toward short sleeved shirts in December. The poor bastards on the 2nd floor were on the opposite schedule.

The old boxes had to be kept within a narrow
temperature range. Mostly that's be 'cooler'
but in winter might be 'hotter'.

I remember an old govt place - a DEC cpu box,
about a cubic meter, discrete transistors - in
the middle of the room and all the tape drive
units along the walls. They kept it about 55/60F
in there at all times WITH an enforced breeze.

BUT ... it supported dozens of serial terminals,
local and remote, and everybody COULD get their
necessary shit done.

Almost *all* COBOL.

Hmmm ... these days you can earn BIG money if
you know, and can fix/mod, COBOL code from the
1960s. Rather a LOT of places paid BIG $$$ to
have COBOL pros write their core operating
software back then - and can now not AFFORD to
port it all over to anything else.

Oh, that olde-tyme COBOL code - SOLID ! Yer
stereotypical white-shirt/narrow-tie guys
who KNEW THEIR SHIT far better than most today.
Not EVER gonna cuss them.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Mon, 17 Aug 2026 00:02:45 -0400, c186282 wrote:

On 8/16/26 06:42, The Natural Philosopher wrote:

On 16/08/2026 09:59, Richard Kettlewell wrote:

c186282 <c186282@nnada.net> writes:

poll() doesnrCOt poll, despite the name.

-a-a Then it should be re-named.

Obviously thatrCOs not happening. And what would be the point? Make life >>> easier for people who react to single words without reading any
documentation?

Of course. Otherwise they might elect Trump as a president...

Listen to the "socialists" - I'd elect Trump over and over until he's
125 years old rather than have THOSE shits in charge of anything.

Yeah, I'm loving that $4.20 gas because he decided to be Netanyahu's
shabbas goy. Sir, hit me again, sir!

The first time around Mexico didn't pay for the wall he didn't build. This time he got into the wars he wasn't going to get into. The news today is
he is stripping down the joint military exercise with South Korea because
he doesn't want to send the wrong message to his fat little buddy in the north.

The guy is a complete wildcard. And, yes, the other side is even worse.
This country is fucked. I'm glad I don't have kids or grandchildren.

--- Synchronet 3.22a-Linux NewsLink 1.2