From Newsgroup: comp.lang.c

So in the days (which probably still exist) of walkie talkies,
people would need to talk one at a time, so say "over"
when they have finished talking.

I have the equivalent of that with my comms software. I
expect that when a remote system has finished sending
screen data (ANSI x3.64 via stdout), and has switched
to reading from stdin, that they send an XON to release
my system, which is blocking on fgetc from stdin or
whatever.

So that's fine, and I want all my software to support that,
including modifying MSDOS 4.0 (where the source is
available) to follow that when "ctty com1:" is in effect.

However, ideally two-way communication would be
possible - still sticking to a slight variation of C90 which
I am calling C90+.

So I was thinking of:

parmnumber = fselect(stdin, comm_fp, NULL);

And the implementation is allowed to block on that, and if
it is going to block, it must block on the first file.

It's also allowed to poll to solve the issue - but that's an
internal detail. And obviously if it's a POSIX system, it
can do a select() on the file numbers, which presumably
doesn't poll. An internal detail.

So the rule is walkie-talkie protocol. But if you are lucky,
you may have 2-way (asynchronous?) communication available.

I thought for coding purposes it would be better to return the
parameter number that first got the data, rather than the file
pointer that first got the data.

And note that if proper protocol said that it was expected
to be the remote's turn to talk, then you would need a
second fselect, with the first parameter being comm_fp this
time.

Any thoughts? Note that I'm not interested in POSIX, I'm
interested in slight changes to C90.

BFN. Paul.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 18 Sep 2025 13:55:16 +0800, Paul Edwards wrote:

And obviously if it's a POSIX system, it can do a select() on the
file numbers ...

select(2) is an antiquated way of doing it. Use poll(2) or epoll(7).

<https://manpages.debian.org/poll(2)>
<https://manpages.debian.org/epoll(7)>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10ag6sc$3m3q1$[email protected]>,
Paul Edwards <[email protected]> wrote:

parmnumber = fselect(stdin, comm_fp, NULL);

I remember writing an fselect() back in the 1980s.

A problem with replicating select() at the FILE level is the buffering
within standard i/o system. The obvious solution is for fselect() to
return immediately if any data is already buffered for any of the
FILEs. That's not ideal because whether standard i/o input functions
block depends on the data itself. Suppose the single character "1"
was buffered, then fgetc() would succeed immediately, but fgets()
would block. All you could really guarantee is that a single fgetc()
would return immediately.

-- Richard
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

"Richard Tobin" <[email protected]> wrote in message news:10agoph$tako$[email protected]...

In article <10ag6sc$3m3q1$[email protected]>,
Paul Edwards <[email protected]> wrote:

parmnumber = fselect(stdin, comm_fp, NULL);

I remember writing an fselect() back in the 1980s.

A problem with replicating select() at the FILE level is the buffering
within standard i/o system. The obvious solution is for fselect() to
return immediately if any data is already buffered for any of the
FILEs. That's not ideal because whether standard i/o input functions
block depends on the data itself. Suppose the single character "1"
was buffered, then fgetc() would succeed immediately, but fgets()
would block. All you could really guarantee is that a single fgetc()
would return immediately.

Sure - for my use case, that would be a massive improvement
over the alternative.

Basically if either party has something to say - indicated by pressing
a single character - then yeah, we'll wait for them to hit enter if that's
the nature of the beast.

But I'm not expecting this to a situation where fgets is ever called.

BFN. Paul.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 18 Sep 2025 11:01:05 -0000 (UTC), Richard Tobin wrote:

A problem with replicating select() at the FILE level is the buffering
within standard i/o system.

Not clear why you feel the need to mix the two.
--- Synchronet 3.21a-Linux NewsLink 1.2