Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 13 Feb 2024 12:54:23 +0000, Ben Bacarisse wrote:
>> (The only advice I'd question is that of using non-block I/O by default.
>> I would be surprised if that helps you in this project, and it might
>> make things more complicated.)
>
> This is why we have the “async” paradigm, a.k.a. the resurgence of
> coroutines.

From coroutines, it's usually one step until somebody again reimplements
cooperative userspace threading. Because of this, I'll take the liberty
here to give a brief (hopefully) abstract description of something I've
found useful for modelling complex asynchronous I/O operations¹. This is
in Perl but should be applicable to any language which supports
closures. It's structured around poll (entirely sufficient for small
numbers of file descriptors) but could be made to work with 'something
else' (eg, epoll) as well.

At the base of this is an I/O completion object I've called a 'want' (as
it describes something a program wants). This object contains a file
handle/ file descriptor, an event the program wants (input available or
output possible) and a continuation closure which should be invoked
after the even has occurred.

At the beginning of each iteration of the main event handling loop,
there's a set of current wants and a poll call is made waiting for any
of the I/O events indicated by these. After something happened and this
call returned, the code goes through the set of active wants and
construct a set of next wants as follows:

If the event a certain want wanted hasn't happened yet, add it to the
next set. If it has happened, call the continuation closure which
returns a possibly empty set of wants. If the set isn't empty, add all
of these to the set of next wants. After all active wants have been
dealt with in this way, make the next set the active set and start the
next iteration of the loop.

¹ Eg, to a REST request. This requires a DNS lookup, establishing a TCP
connection, doing a TLS handshake, sending the request and processing
the reply. This involves 2 different file descriptors and multiple I/O
event 'mode switches', waiting for a different kind of event for a file
descriptor than the last one. Establishing a TCP connection
asynchronously is a 'ready for write' event. The following TLS handshake
will at least need to wait for 'input available' but may need both of
them in some a priori unpredictable sequence.

On Tue, 13 Feb 2024 21:09:45 +0000, Rainer Weikusat wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> This is why we have the “async” paradigm, a.k.a. the resurgence of
>> coroutines.
>
> From coroutines, it's usually one step until somebody again reimplements
> cooperative userspace threading.

That’s what “async” is all about. In Python asyncio, they use the term
“tasks” for these cooperative schedulable entities. They are wrappers
around Python coroutine objects.

> At the base of this is an I/O completion object I've called a 'want' (as
> it describes something a program wants). This object contains a file
> handle/ file descriptor, an event the program wants (input available or
> output possible) and a continuation closure which should be invoked
> after the even has occurred.

In the Python asyncio library, there is this concept of a “future”. In
JavaScript, they call it a “promise”. This is not tied in any way to
particular open files or anything else: think of it as a box, initially
empty, with a sign above it saying “watch this space”. At some point,
something should happen, and tasks can block on waiting for it. When
something appears in the box, they are woken up and can retrieve a copy of
the contents.

In Python asyncio, you can also set an exception on the future. So instead
of getting back a value, each waiting task gets the exception raised in
their context.

> At the beginning of each iteration of the main event handling loop,
> there's a set of current wants and a poll call is made waiting for any
> of the I/O events indicated by these.

Not just I/O events, you also want timers as well.

Rainer Weikusat <rweikusat@talktalk.net> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>
> [...]
>
>>> IF I
>>>
>>> char vrm[16];
>>> fscanf(fd,"Asterisk Call Manager/%s\r\n",vrm);
>>>
>>> to extract the AMI version number that follows the text slash, my
>>> fscanf() hangs.
>
> [...]
>
>> The scanf functions are not intuitive -- you really have to read the
>> manual carefully. The trouble you are having is that space characters
>> are directives and are not treated literally. The \r directs fscanf to
>> read one or more space characters, and it won't stop trying until it
>> reads a non-space character.
>
> This is specifically demanded by the UNIX specification:
>
> ,----
> | A directive composed of one or more white-space characters shall be
> | executed by reading input until no more valid input can be read, or up
> | to the first byte which is not a white-space character, which remains
> | unread.
> `----

And by the ISO C standard:

A directive composed of white-space character(s) is executed by
reading input up to the first non-white-space character (which
remains unread), or until no more characters can be read. The
directive never fails.
[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 13 Feb 2024 21:09:45 +0000, Rainer Weikusat wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> This is why we have the “async” paradigm, a.k.a. the resurgence of
>>> coroutines.
>>
>> From coroutines, it's usually one step until somebody again reimplements
>> cooperative userspace threading.
>
> That’s what “async” is all about. In Python asyncio, they use the term
> “tasks” for these cooperative schedulable entities. They are wrappers
> around Python coroutine objects.

No, it's not. That's an overgeneralisation of a useful concept people
keep reinventing (I just found another one or two weeks ago).

>> At the base of this is an I/O completion object I've called a 'want' (as
>> it describes something a program wants). This object contains a file
>> handle/ file descriptor, an event the program wants (input available or
>> output possible) and a continuation closure which should be invoked
>> after the even has occurred.
>
> In the Python asyncio library, there is this concept of a “future”. In
> JavaScript, they call it a “promise”. This is not tied in any way to
> particular open files or anything else: think of it as a box, initially
> empty, with a sign above it saying “watch this space”. At some point,
> something should happen, and tasks can block on waiting for it. When
> something appears in the box, they are woken up and can retrieve a copy of
> the contents.

And that's another overgeneralization, see below.

[...]

>> At the beginning of each iteration of the main event handling loop,
>> there's a set of current wants and a poll call is made waiting for any
>> of the I/O events indicated by these.
>
> Not just I/O events, you also want timers as well.

On Linux, timers and - more generally - other signal-driven things are
I/O events. It's possible to receive signals on file descriptor via
signalfd which - in combination with setitimer, can be used to provide
arbitrary timer events. It's also possible to get timer events directly
via file descriptor by using 'timer' fds (=> timerfd_create and
friends). I haven't found a real use for these so far,
though. Programming alarms and using these to activate timers based on
some data structure for storing them (eg, a sorted linked list or a
more elaborate priority queue) has been sufficient for me so far.

On Tue, 13 Feb 2024 21:57:54 +0000, Rainer Weikusat wrote:

> That's an overgeneralisation of a useful concept people
> keep reinventing ...

If it really was a generalization, then there would be nothing to
“reinvent”. You only need to “reinvent” something if a prior concept was
not general enough.

TL;DR: “overgeneralization ... you keep using that word ... I do not think
it means what you think it means”.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 13 Feb 2024 21:57:54 +0000, Rainer Weikusat wrote:
>
>> That's an overgeneralisation of a useful concept people
>> keep reinventing ...
>
> If it really was a generalization, then there would be nothing to
> “reinvent”. You only need to “reinvent” something if a prior concept was
> not general enough.

Surely, as someone who claims to have programmed something the past, you
must be aware that it's possible to reimplement or reprogram something
somebody else already implemented/ programmed in the past, ie, creating (yet
another) green threads implementation.

> TL;DR: “overgeneralization ... you keep using that word ... I do not think
> it means what you think it means”.

If you think that you're thinking, you're only thinking that you're
thinking.
 Yes, this is silly. But so is becoming abusive within two posts for
absolutely no reason.

On 2024-02-13, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 13 Feb 2024 21:57:54 +0000, Rainer Weikusat wrote:
>
>> That's an overgeneralisation of a useful concept people
>> keep reinventing ...
>
> If it really was a generalization, then there would be nothing to
> “reinvent”. You only need to “reinvent” something if a prior concept was
> not general enough.

Nope! How it works in computing is that people "reinvent" something if
they have no clue it existed before, and describe it using different
terminology.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Lew Pitcher , dans le message <uqg4tl$23ni8$10@dont-email.me>, a écrit :
> Indeed, I did. And your point is?

I am trying to determine if you belive that Usenet counts as “laboratory
conditions”.

Rainer Weikusat , dans le message
<875xyspcmm.fsf@doppelsaurus.mobileactivedefense.com>, a écrit :
> The idea behind non-blocking I/O is usually that of a single-threaded
> program (or a single thread of a program) which needs to handle
> real-time input¹ on more than one file descriptor and thus, cannot block
> waiting for input on one of them as data might arrive at one of the
> others first.

While true, your statement is misleading by bringing threads into the
discussion: it seems to imply that threads would be a solution to use the
convenience of blocking I/O with real-time programs.

But the idea that threads solve I/O concurrency issues is a misconception.
The design POSIX thread API entirely ignores the file descriptor API, and
therefore instead of helping making fd I/O easier, it makes it harder.
People who try to solve concurrent I/O with threads achieve something first,
but as soon as they start implementing the necessary features like timeout
they realize they need to put an event-loop, poll()-based or other, in most
of their threads, while they hoped to avoid an event-loop in their
single-threaded program.

POSIX threads are useful for performance, but it is a mistake to think they
help for I/O. And that mistake is pervasive enough that we must be careful
not to amplify it.

On 13 Feb 2024 22:35:41 GMT, Nicolas George wrote:

> POSIX threads are useful for performance, but it is a mistake to think
> they help for I/O. And that mistake is pervasive enough that we must be
> careful not to amplify it.

The 1990s were very much the “decade of threads”, weren’t they. The
concept was just starting to become pervasive across the OSes of the time,
and people wanted to use them for everything, even GUIs.

Multithreading in GUIs (e.g. Sun’s NeWS) turned out to be a mistake.

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> [..]
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> On Tue, 13 Feb 2024 12:54:23 +0000, Ben Bacarisse wrote:
[...]

>>>> (The only advice I'd question is that of using non-block I/O by
>>>> default. I would be surprised if that helps you in this project,
>>>> and it might make things more complicated.)
>>>
>>> I've done less programming with non-blocking I/O than I've done
>>> with sockets. I have heard the advice to use non-blocking I/O,
>>> and will consider it, but I don't want to take on too much in one
>>> shot.
>> [...]
>
> For this mini-project, both client and server live on the same
> machine, and communicate through the loopback ("localhost").
> There won't be any significant latency issues or other
> communications interference.
>
> I'm only concerned with writing the client, and it will only
> interact over one channel in a simple request/reply type protocol.
> There doesn't seem to be a pressing need for nonblocking I/O.
>
> But, as it has been suggested here, I will look into nonblocking
> I/O. Perhaps I'm missing something that others have seen.

I guess I should expand on the idea that using non-blocking I/O
is a good idea.

First, my comment was offered as pragmatic advice following many
years of experience both with networking and with socket-level
programming. It is generic advice, given without taking into
account any of the specifics of your project. There is no question
that using non-blocking I/O means more work up front, and I expect
there is a good chance you could get something working without doing
any of the non-blocking stuff.

That said, here are some things to think about.

Although there is only one channel, there are two communication
paths: one for reading and one for writing. If there were really
only one path (e.g., reading a file and writing to a socket) then
using blocking I/O is probably good enough. But any more than
just a single path makes things more complicated.

There can be problems at the protocol level even if the transport
layer is working perfectly. Network programming has a lot in
common with inter-process synchronization, and is just as tricky
except in the cases where it's even trickier. How is the remote
process (which is Asterisk in this case) going to behave? That
can (and often does) matter.

(Incidentally, speaking of Asterisk, Asterisk is great! I've
been running my own home phone system on Asterisk for more than a
decade now, and I'd never give it up.)

As far as the transport layer goes, TCP is very reliable once it
gets going, but there is a little dance that happens at the start
to get things set up, and sometimes one of the partners steps on
the other's foot. I see this happen sporadically with programs
that have the same basic outline as your application (one socket
used for both reading and writing). Probably there is some sort
of interaction with what's going on at the protocol level, but
it's hard to know whether the problem is a protocol issue or
something in one of the network layers.

Assuming you do go ahead with using blocking I/O, and get things
working, there is still a fair chance that at some point down the
road (probably after the application has been deployed) the program
will be the victim of a network hiccup and go catatonic. If and
when that happens: one, it will be frustrating; two, the problem
will be non-reproducible; and three, you won't have any tools to
help diagnose what's going on to cause the problem, because all the
significant events are happening inside one of the blocking system
calls. Conversely, if all the socket I/O is non-blocking, the code
can be instrumented (whether before the fact or after) with various
sorts of logging, and the log information can be examined to see
what's going on.

Final point: probably the most important lesson here is that we
may expect that network system calls are going to fail, and should
program accordingly. When working with files it's easy to get
into the habit of thinking the calls will never fail, because they
almost never do. Network system calls are different. They might
not fail all the time, but they *are* going to fail, and it's
better to anticipate that, and program accordingly. Using
non-blocking I/O makes that easier, partly because "failures"
happen more often in the form of "operation would block", so one
gets into the habit of writing code that handles different kinds
of error returns. This means a little more work at the outset,
but ultimately less work (we hope!) overall.

I guess I should add that I'm not trying to persuade anyone, and
please go ahead as you think best. I thought it might be helpful
to explain some of the rationale underlying my suggestion, and
hence this response.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

[...]

> I guess I should expand on the idea that using non-blocking I/O
> is a good idea.
>
> First, my comment was offered as pragmatic advice following many
> years of experience both with networking and with socket-level
> programming. It is generic advice, given without taking into
> account any of the specifics of your project.

[...]

Ie, this is about using a certain model for handling I/O (specifically,
as originally suggested, busy-polling with interspersed sleeps)
regardless of the actual needs of an application.

[long general statement whose relevance I don't understand]

> Assuming you do go ahead with using blocking I/O, and get things
> working, there is still a fair chance that at some point down the
> road (probably after the application has been deployed) the program
> will be the victim of a network hiccup and go catatonic.

That's pretty much guaranteed to happen as all kinds of 'network
demolition devices' (commonly called firewalls) will silently cut off
perfectly working TCP connections, either because these have exceeded
some idle time their masters considered just too much or because they
have been rebooted or are malfunctioning. But this is only relevant for
long-running, non-interactive programs and will usually need some scheme
for periodic keepalive exchanges to detect connections which have
silenty gone bad.

> If and when that happens: one, it will be frustrating; two, the problem
> will be non-reproducible; and three, you won't have any tools to
> help diagnose what's going on to cause the problem, because all the
> significant events are happening inside one of the blocking system
> calls. Conversely, if all the socket I/O is non-blocking, the code
> can be instrumented (whether before the fact or after) with various
> sorts of logging, and the log information can be examined to see
> what's going on.

With non-blocking I/O, all significant events still happen inside the
kernel, it's just that the program is hammering the kernel with
avoidable system calls.

> Final point: probably the most important lesson here is that we
> may expect that network system calls are going to fail, and should
> program accordingly. When working with files it's easy to get
> into the habit of thinking the calls will never fail, because they
> almost never do. Network system calls are different. They might
> not fail all the time, but they *are* going to fail, and it's
> better to anticipate that, and program accordingly. Using
> non-blocking I/O makes that easier, partly because "failures"
> happen more often in the form of "operation would block", so one
> gets into the habit of writing code that handles different kinds
> of error returns. This means a little more work at the outset,
> but ultimately less work (we hope!) overall.

It's perfectly possible to implement handling for network errors without
introducing EAGAIN pseudo-errors in situations where they don't make
much sense (such as using a request-response protocol over a single TCP
connection).