Muttley@DastardlyHQ.org writes:
>On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
>>>Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>>>On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>>>>
>>>>> For instance, is there any Windows software that
>>>>> handles a TCP connection in an accept-fork-exec fashion?
>>>>
>>>>Almost certainly not. Because process creation is an expensive operation
>>>>on Windows.
>>>>
>>>>Windows NT was masterminded by Dave Cutler, who was previously responsible
>>>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
>>>>a bunch of them at DEC. They would instinctively turn away from Unix ways
>>>>of doing things, like forking multiple processes. So the systems they
>>>>created did not encourage such techniques.
>>>
>>>Presumably VMS relied heavily on multithreading then like Windows or was a
>>>process expected to everything itself sequentially?
>>
>>Many system services on VMS are asynchronous, and the system
>>architecture provides a mechanisms to signal completion; ASTs,
>>mailboxes, etc. Thus, many programs (not all) on VMS are
>>written in a callback/closure style.
>
>I imagine that could become complicated very quickly and presumably relies
>on the OS providing the signalling mechanisms for everything you might
>want to do - eg waiting for a socket connection (or whatever the decnet
>equivalent was).

Actually, it was straightfoward to use and rather elegent. You
could build a nice asynchronous transfer algorithm just using AST's
a and/or event flags.

Muttley@DastardlyHQ.org writes:
>On Mon, 6 Jan 2025 14:08:44 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>In article <vlg4mb$1hi6d$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>>On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
>>>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>>>In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>>>>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
>>>>>Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>>>>>On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>>>>>>
>>>>>>> For instance, is there any Windows software that
>>>>>>> handles a TCP connection in an accept-fork-exec fashion?
>>>>>>
>>>>>>Almost certainly not. Because process creation is an expensive operation
>>>>>>on Windows.
>>>>>>
>>>>>>Windows NT was masterminded by Dave Cutler, who was previously responsible
>>
>>>>>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
>>
>>>>>>a bunch of them at DEC. They would instinctively turn away from Unix ways
>>>>>>of doing things, like forking multiple processes. So the systems they
>>>>>>created did not encourage such techniques.
>>>>>
>>>>>Presumably VMS relied heavily on multithreading then like Windows or was a
>>>>>process expected to everything itself sequentially?
>>>>
>>>>Many system services on VMS are asynchronous, and the system
>>>>architecture provides a mechanisms to signal completion; ASTs,
>>>>mailboxes, etc. Thus, many programs (not all) on VMS are
>>>>written in a callback/closure style.
>>>
>>>I imagine that could become complicated very quickly and presumably relies
>>>on the OS providing the signalling mechanisms for everything you might
>>>want to do - eg waiting for a socket connection (or whatever the decnet
>>>equivalent was).
>>
>>It's a fairly common way to structure software even today. As I
>
>In Windows yes, which frankly is probably not a coincidence. Not so much
>in unix unless you're writing a GUI program.

ASTs and unix signals have similar semantics. It's certainly possible to
use, for example, SIGIO in a similar manner to the VMS AST, where the
AST signals I/O completion and the AST handler initiates a subsequent
operation.

In article <vlgots$1le5s$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>On Mon, 6 Jan 2025 14:08:44 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>In article <vlg4mb$1hi6d$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>>On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
>>>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>>>In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>>>>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
>>>>>Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>>>>>On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>>>>>>
>>>>>>> For instance, is there any Windows software that
>>>>>>> handles a TCP connection in an accept-fork-exec fashion?
>>>>>>
>>>>>>Almost certainly not. Because process creation is an expensive operation
>>>>>>on Windows.
>>>>>>
>>>>>>Windows NT was masterminded by Dave Cutler, who was previously responsible
>>
>>>>>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
>>
>>>>>>a bunch of them at DEC. They would instinctively turn away from Unix ways
>>>>>>of doing things, like forking multiple processes. So the systems they
>>>>>>created did not encourage such techniques.
>>>>>
>>>>>Presumably VMS relied heavily on multithreading then like Windows or was a
>>>>>process expected to everything itself sequentially?
>>>>
>>>>Many system services on VMS are asynchronous, and the system
>>>>architecture provides a mechanisms to signal completion; ASTs,
>>>>mailboxes, etc. Thus, many programs (not all) on VMS are
>>>>written in a callback/closure style.
>>>
>>>I imagine that could become complicated very quickly and presumably relies
>>>on the OS providing the signalling mechanisms for everything you might
>>>want to do - eg waiting for a socket connection (or whatever the decnet
>>>equivalent was).
>>
>>It's a fairly common way to structure software even today. As I
>
>In Windows yes, which frankly is probably not a coincidence. Not so much
>in unix unless you're writing a GUI program.

Very much in Unix, actually. The kernel is highly asynchronous
(it must be, to match the hardware), and has been since the
early 1970s. Many user programs similarly.

Historically, many systems have provided direct support for
asynchronous programming on Unix. Going back to the early
commerical Unix days, masscomp's real time Unix had ASTs, not
signals, to support asynch IO directly from userspace. More
recently, POSIX.1b and POSIX AIO are widely supported. Polling
interfaces like kqueue and epoll, etc, exist largely to support
multiplexing asynchronous tasks, though not using the callback
model per se (one polls a set of e.g. file descriptors and
dispatches explicitly based on their states as reported by the
polling interface). Most recently, things like io_uring on
Linux are designed specifically to support asynch IO in user
programs.

Granted, the Unix system interface is not particularly
asynchronous-friendly, but that is by design. As Doug McIlroy
put it,

|The infrastructure had to be asynchronous. The whole point was
|to surmount that difficult model and keep everyday programming
|simple. User visibility of asynchrony was held to a minimum:
|fork(), signal(), wait(). Signal() was there first and
|foremost to support SIGKILL; it did not purport to provide a
|sound basis for asynchronous IPC.
(https://tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/message/IAAO2MRTMSX3C54YGTNOTIT4FEQA73IR/)

This was fine for writing `cat` and `cp` etc, which were largely
synchronous anyway. Less so for server-style programs or
programs that had to multiplex data from many sources generally.

This early decision to favor the comprehensibility of one class
of program in the system call interface has had reverberations
through time, leading to much complexity. This is one reason
that, for example, the Go runtime has to jump through so many
hoops to mux goroutines onto the underlying OS-provided thread
abstraction; or that the implementation of async executors for
Rust is hard (cf Tokio). In that same message referenced above,
Doug continues:

|The complexity of sigaction() is evidence that asynchrony
|remains untamed 40 years on.

This is unfair. It's evidence that grafting it onto an existing
highly synchronous system interface that was simply not designed
to accommodate it in the first place is very hard, even 50 years
after the fact.

- Dan C.

On Mon, 06 Jan 2025 15:05:33 GMT
scott@slp53.sl.home (Scott Lurndal) wibbled:
>Muttley@DastardlyHQ.org writes:
>>In Windows yes, which frankly is probably not a coincidence. Not so much
>>in unix unless you're writing a GUI program.
>
>ASTs and unix signals have similar semantics. It's certainly possible to
>use, for example, SIGIO in a similar manner to the VMS AST, where the
>AST signals I/O completion and the AST handler initiates a subsequent
>operation.

Unix signals should only be used to set flags that are then read later. Doing
anything complicated in a signal handler is asking for trouble as you have
no idea where the program was when the signal occured and there can be all
sorts of re-entrant issues or even deadlocks if using mutexes.

On Mon, 6 Jan 2025 15:22:51 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>In article <vlgots$1le5s$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>In Windows yes, which frankly is probably not a coincidence. Not so much
>>in unix unless you're writing a GUI program.
>
>Very much in Unix, actually. The kernel is highly asynchronous
>(it must be, to match the hardware), and has been since the
>early 1970s. Many user programs similarly.
>
>Historically, many systems have provided direct support for
>asynchronous programming on Unix. Going back to the early
>commerical Unix days, masscomp's real time Unix had ASTs, not
>signals, to support asynch IO directly from userspace. More
>recently, POSIX.1b and POSIX AIO are widely supported. Polling
>interfaces like kqueue and epoll, etc, exist largely to support

Multiplexing is not asychronous, its simply offloading status checking to
the kernel. The program using is still very much sequential , at least at
that point.

Posix AIO is not asynch in the strict sense , its more "ok kernel, go do this
and I'll check how you're doing later". Proper asynch where the program
execution path gets bounced around between various callbacks is something
else entirely.

In article <vlgun1$1minf$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>On Mon, 6 Jan 2025 15:22:51 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>In article <vlgots$1le5s$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>>In Windows yes, which frankly is probably not a coincidence. Not so much
>>>in unix unless you're writing a GUI program.
>>
>>Very much in Unix, actually. The kernel is highly asynchronous
>>(it must be, to match the hardware), and has been since the
>>early 1970s. Many user programs similarly.
>>
>>Historically, many systems have provided direct support for
>>asynchronous programming on Unix. Going back to the early
>>commerical Unix days, masscomp's real time Unix had ASTs, not
>>signals, to support asynch IO directly from userspace. More
>>recently, POSIX.1b and POSIX AIO are widely supported. Polling
>>interfaces like kqueue and epoll, etc, exist largely to support
>
>Multiplexing is not asychronous, its simply offloading status checking to
>the kernel.

Of course. It's a means to allow a program to respond to
asynchronous events.

>The program using is still very much sequential , at least at
>that point.

But the events are not. That's the point. This allows a
program to initiate a non-blocking IO operation (like, say,
establishing a TCP connection using the sockets API), go do
something else, and check it's status later.

>Posix AIO is not asynch in the strict sense , its more "ok kernel, go do this
>and I'll check how you're doing later". Proper asynch where the program
>execution path gets bounced around between various callbacks is something
>else entirely.

The POSIX AIO interface allows the kernel to generate a signal
to inform the program that an IO operation has completed, e.g.,
by setting up the `aio_sigevent` and `SIGEV_SIGNAL`. It doesn't
get much more asynchronous than that.

- Dan C.

Muttley@DastardlyHQ.org writes:
>On Mon, 06 Jan 2025 15:05:33 GMT
>scott@slp53.sl.home (Scott Lurndal) wibbled:
>>Muttley@DastardlyHQ.org writes:
>>>In Windows yes, which frankly is probably not a coincidence. Not so much
>>>in unix unless you're writing a GUI program.
>>
>>ASTs and unix signals have similar semantics. It's certainly possible to
>>use, for example, SIGIO in a similar manner to the VMS AST, where the
>>AST signals I/O completion and the AST handler initiates a subsequent
>>operation.
>
>Unix signals should only be used to set flags that are then read later.

You're opinion is not widely shared. Note that the POSIX specification
carefully notes which interfaces are not signal-safe.

On 1/6/25 11:46, Scott Lurndal wrote:
> Muttley@DastardlyHQ.org writes:
....
>> Unix signals should only be used to set flags that are then read later.
>
> You're opinion is not widely shared. Note that the POSIX specification
> carefully notes which interfaces are not signal-safe.

What precisely does "signal-safe" mean? As I understand it, it is
supposed to be safe for a signal to interrupt standard library routines,
but that it's not safe for a signal handler to call most of those
functions. There's just a few exceptions, described below.

The C standard says the following about signal handlers:
"The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static or thread storage duration.
239)" (7.1.4p4)
Footnote 239 says "Thus, a signal handler cannot, in general, call
standard library functions."

"If the signal occurs other than as the result of calling the abort or
raise function, the behavior is undefined if the signal handler refers
to any object with static or thread storage duration that is not a
lock-free atomic object and that is not declared with the constexpr
storage-class specifier other than by assigning a value to an object
declared as volatile sig_atomic_t, or the signal handler calls any
function in the standard library other than
— the abort function,
— the _Exit function,
— the quick_exit function,
— the functions in <stdatomic.h> (except where explicitly stated
otherwise) when the atomic arguments are lock-free,
— the atomic_is_lock_free function with any atomic argument, or
— the signal function with the first argument equal to the signal number
corresponding to the signal that caused the invocation of the handler.
Furthermore, if such a call to the signal function results in a SIG_ERR
return, the object designated by errno has an indeterminate
representation.310)" (7.14.1.1p5)
Footnote 310 says "If any signal is generated by an asynchronous signal
handler, the behavior is undefined."

"If a signal occurs other than as the result of calling the abort or
raise functions, the behavior is undefined if the signal handler reads
or modifies an atomic object that has an indeterminate representation."
(7.17.2p2)

"If a signal occurs other than as the result of calling the abort or
raise functions, the behavior is undefined if the signal handler calls
the atomic_init generic function." (7.17.2.1p4)

The POSIX standard claims that its version of <signal.h> conforms to the
C standard, and as far as I can see, the POSIX standard doesn't say
anything to define the behavior that is undefined by the C standard.

Could you demonstrate how, within the above restrictions, a signal
handler that doesn't cause the program to exit in one fashion or another
could do anything useful other than "set flags that are read later"?
I'm not saying it cannot be done. I claim no expertise in this kind of
programming - I never needed to write signal handlers. However, the last
time I considered the matter carefully (which was two or three versions
of the C standard ago) I couldn't figure out how to do much more than
that. At that time I did not consider how POSIX affects the issue, and I
don't know enough about POSIX signals to evaluate that issue.

Muttley@dastardlyhq.org wrote:
> Unix signals should only be used to set flags that are then read later. Doing
> anything complicated in a signal handler is asking for trouble as you have
> no idea where the program was when the signal occured and there can be all
> sorts of re-entrant issues or even deadlocks if using mutexes.

That is what I have learned, too, but I cannot remember the
source. Maybe one of Richard Stevens' UNIX books.

I am no expert, but I guess if you need to do async programming
on UNIX/Linux userspace, your best is to use POSIX Threads.

br,
KK

In article <vlh4mo$1nccc$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 1/6/25 11:46, Scott Lurndal wrote:
>> Muttley@DastardlyHQ.org writes:
>...
>>> Unix signals should only be used to set flags that are then read later.
>>
>> You're opinion is not widely shared. Note that the POSIX specification
>> carefully notes which interfaces are not signal-safe.
>
>What precisely does "signal-safe" mean? As I understand it, it is
>supposed to be safe for a signal to interrupt standard library routines,
>but that it's not safe for a signal handler to call most of those
>functions. There's just a few exceptions, described below.

From POSIX 2024, sectino 2.4 ("Signal Concepts"):

|The following table defines a set of functions and
|function-like macros that shall be async-signal-safe.
|Therefore, applications can call them, without restriction,
|from signal-catching functions. Note that, although there is
|no restriction on the calls themselves, for certain functions
|there are restrictions on subsequent behavior after the
|function is called from a signal-catching function (see longjmp()).
(https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04)

(The table mentioned above includes over 200 functions.)

>The C standard says the following about signal handlers:
>"The functions in the standard library are not guaranteed to be
>reentrant and may modify objects with static or thread storage duration.
>239)" (7.1.4p4)
>Footnote 239 says "Thus, a signal handler cannot, in general, call
>standard library functions."

This is comp.unix.programmer, not comp.lang.c.

>[snip]
>
>"If a signal occurs other than as the result of calling the abort or
>raise functions, the behavior is undefined if the signal handler reads
>or modifies an atomic object that has an indeterminate representation."
>(7.17.2p2)
>
>"If a signal occurs other than as the result of calling the abort or
>raise functions, the behavior is undefined if the signal handler calls
>the atomic_init generic function." (7.17.2.1p4)
>
>The POSIX standard claims that its version of <signal.h> conforms to the
>C standard, and as far as I can see, the POSIX standard doesn't say
>anything to define the behavior that is undefined by the C standard.

This is factually incorrect.

>Could you demonstrate how, within the above restrictions, a signal
>handler that doesn't cause the program to exit in one fashion or another
>could do anything useful other than "set flags that are read later"?

Those restrictions don't apply in this context. But a trivial
example:

void
reaper(int signo)
{
(void)signo;
wait(NULL);
}

/* ... */
signal(SIGCHLD, reaper);

>I'm not saying it cannot be done. I claim no expertise in this kind of
>programming - I never needed to write signal handlers.

Perhaps read up on the matter before commenting, then?

>However, the last
>time I considered the matter carefully (which was two or three versions
>of the C standard ago) I couldn't figure out how to do much more than
>that. At that time I did not consider how POSIX affects the issue, and I
>don't know enough about POSIX signals to evaluate that issue.

In strict C, this is correct. But while POSIX includes ISO C as
a subset, it extends allowable behavior in lots of places to
both standardize the behavior of existing programs as well as
make it possible to write useful programs on Unix-style systems.

- Dan C.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 1/6/25 11:46, Scott Lurndal wrote:
>> Muttley@DastardlyHQ.org writes:
> ...
>>> Unix signals should only be used to set flags that are then read later.
>>
>> You're opinion is not widely shared. Note that the POSIX specification
>> carefully notes which interfaces are not signal-safe.
>
> What precisely does "signal-safe" mean?

The UNIX standard has meanwhile started to contradict itself on this
topic because of the apparent attempt to follow the (pretty silly) C++
memory model incorporated into C for no particular reason. But the
relevant part of the UNIX definition (still part of the current
definition) used to be

In the presence of signals, all functions defined by this volume
of POSIX.1-2024 shall behave as defined when called from or
interrupted by a signal-catching function, with the exception
that when a signal interrupts an unsafe function or
function-like macro, or equivalent (such as the processing
equivalent to exit() performed after a return from the initial
call to main()), and the signal-catching function calls an
unsafe function or function-like macro, the behavior is
undefined.

This text is below the list of async-signal safe interfaces. It
contradicts the

the behavior is undefined if:

[...]

The signal handler calls any function or function-like macro
defined in this standard other than one of the functions and
macros specified below as being async-signal-safe.

immediately above it.

https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04

When ignoring the apparent attempt at making signals really impossible
to use, "async signal-safe" is really quite simple: Any handler can do
anything provided it doesn't invoke some kind of not async signal safe
interface. A handler which didn't interrupt an interface that's not
async signal safe can anything, including calling unsafe functions.

A usual way to achieve the latter is to keep signals blocked except when
calling an async signal safe functions, eg, pselect, ppoll or
sigsuspend.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>On 1/6/25 11:46, Scott Lurndal wrote:
>> Muttley@DastardlyHQ.org writes:
>...
>>> Unix signals should only be used to set flags that are then read later.
>>
>> You're opinion is not widely shared. Note that the POSIX specification
>> carefully notes which interfaces are not signal-safe.
>

>Could you demonstrate how, within the above restrictions, a signal
>handler that doesn't cause the program to exit in one fashion or another
>could do anything useful other than "set flags that are read later"?
>I'm not saying it cannot be done. I claim no expertise in this kind of
>programming - I never needed to write signal handlers. However, the last
>time I considered the matter carefully (which was two or three versions
>of the C standard ago) I couldn't figure out how to do much more than
>that. At that time I did not consider how POSIX affects the issue, and I
>don't know enough about POSIX signals to evaluate that issue.

Augmenting Dan's well-written response, I'd point out that those
POSIX interfaces (many of which are system calls, not library
functions) are designed to work with signals. One common
technique is to call longjmp() from within a SIGINT handler;
all the application must do is mask the signal if/when executing
in a non-async-signal-safe critical section. Note that a signal
(with a few exceptions) will not interrupt a system call, and when
it does, the system call returns EINTR to the caller without any
other caller-visible side effects (either the system call fully
completes before the signal is delivered, or it has no effect).

On Mon, 6 Jan 2025 14:21:48 -0000 (UTC), Muttley wrote:

> Not so much in unix unless you're writing a GUI program.

In *nix, select/poll works well when the performance bottleneck resides in
the I/O. async/await lets you linearize the logic of your handlers for
easier comprehension, instead of breaking them up into separate calback
stages.

async/await is also useful in GUI programs, for the same reason.

On Mon, 6 Jan 2025 16:00:33 -0000 (UTC), Muttley wrote:

> Posix AIO is not asynch in the strict sense , its more "ok kernel, go do
> this and I'll check how you're doing later".

POSIX has “real-time signals”, which are very similar to VMS ASTs.

On Mon, 6 Jan 2025 17:53:20 -0000 (UTC), Kalevi Kolttonen wrote:

> I am no expert, but I guess if you need to do async programming on
> UNIX/Linux userspace, your best is to use POSIX Threads.

Threads are something you normally want to avoid, unless CPU usage is the
bottleneck in your application.

In the case where the limiting factor is I/O or network bandwidth, or a
GUI app waiting for user input, then async/await is a more convenient
paradigm.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Mon, 6 Jan 2025 16:00:33 -0000 (UTC), Muttley wrote:
>
>> Posix AIO is not asynch in the strict sense , its more "ok kernel, go do
>> this and I'll check how you're doing later".
>
>POSIX has “real-time signals”, which are very similar to VMS ASTs.

In any case, lio_listio is sufficiently asynchronous to be useful
in e.g. Oracle.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Mon, 6 Jan 2025 17:53:20 -0000 (UTC), Kalevi Kolttonen wrote:
>
>> I am no expert, but I guess if you need to do async programming on
>> UNIX/Linux userspace, your best is to use POSIX Threads.
>
>Threads are something you normally want to avoid, unless CPU usage is the
>bottleneck in your application.

Complete and utter nonsense.

In article <z9XeP.3$TgDc.2@fx38.iad>, Scott Lurndal <slp53@pacbell.net> wrote:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Mon, 6 Jan 2025 17:53:20 -0000 (UTC), Kalevi Kolttonen wrote:
>>
>>> I am no expert, but I guess if you need to do async programming on
>>> UNIX/Linux userspace, your best is to use POSIX Threads.
>>
>>Threads are something you normally want to avoid, unless CPU usage is the
>>bottleneck in your application.
>
>Complete and utter nonsense.

As you would expect, cosidering the source.

--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

Kalevi Kolttonen, dans le message <vlh5ag$1nruu$1@dont-email.me>, a
écrit :
> I am no expert, but I guess if you need to do async programming
> on UNIX/Linux userspace, your best is to use POSIX Threads.

Very common misconception. The communication mechanisms between POSIX
threads and Unix I/O are completely alien to each-other: it is not possible
to poll() on a thread condition, nor is it it possible to set up a condition
to be woken by data on a file descriptor. As a result, anybody who tries to
use threads to solve problems of I/O concurrency ends up having to implement
a poll() or equivalent loop in each thread, defeating the purpose.

POSIX threads are good to improve on computation concurrency, but they do
not make I/O concurrency simpler, quite the opposite.

The same might not be true for other kinds of threads.

On 07 Jan 2025 00:49:32 GMT, Nicolas George wrote:

> The communication mechanisms between POSIX
> threads and Unix I/O are completely alien to each-other: it is not
> possible to poll() on a thread condition, nor is it it possible to set
> up a condition to be woken by data on a file descriptor.

Linux offers signalfd, so you can indeed use poll(2) in a thread to be
woken up by any file descriptor, including a signal one (and that includes
POSIX real-time signals).

On Mon, 6 Jan 2025 16:39:49 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>In article <vlgun1$1minf$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>On Mon, 6 Jan 2025 15:22:51 -0000 (UTC)
>>Multiplexing is not asychronous, its simply offloading status checking to
>>the kernel.
>
>Of course. It's a means to allow a program to respond to
>asynchronous events.

Thats not the same as the program itself being asynch.

>>The program using is still very much sequential , at least at
>>that point.
>
>But the events are not. That's the point. This allows a
>program to initiate a non-blocking IO operation (like, say,
>establishing a TCP connection using the sockets API), go do
>something else, and check it's status later.

Thats not proper asych, its still sequential. Proper asynch is when the
program execution path is directly modified by external events. Otherwise
you could claim simply using the standard file I/O system is asynchronous
programming as there's no guarantee that any data has been written to the disk
before write(), fprintf() etc return.

>>Posix AIO is not asynch in the strict sense , its more "ok kernel, go do this
>>and I'll check how you're doing later". Proper asynch where the program
>>execution path gets bounced around between various callbacks is something
>>else entirely.
>
>The POSIX AIO interface allows the kernel to generate a signal
>to inform the program that an IO operation has completed, e.g.,
>by setting up the `aio_sigevent` and `SIGEV_SIGNAL`. It doesn't
>get much more asynchronous than that.

Sure, but as I've said before, signals should only set flags to be processed
later.

On Mon, 06 Jan 2025 16:46:56 GMT
scott@slp53.sl.home (Scott Lurndal) wibbled:
>Muttley@DastardlyHQ.org writes:
>>On Mon, 06 Jan 2025 15:05:33 GMT
>>scott@slp53.sl.home (Scott Lurndal) wibbled:
>>>Muttley@DastardlyHQ.org writes:
>>>>In Windows yes, which frankly is probably not a coincidence. Not so much
>>>>in unix unless you're writing a GUI program.
>>>
>>>ASTs and unix signals have similar semantics. It's certainly possible to
>>>use, for example, SIGIO in a similar manner to the VMS AST, where the
>>>AST signals I/O completion and the AST handler initiates a subsequent
>>>operation.
>>
>>Unix signals should only be used to set flags that are then read later.
>
>You're opinion is not widely shared. Note that the POSIX specification
>carefully notes which interfaces are not signal-safe.

ITYF it is VERY widely shared and having a signal safe API function is only
step 2 - plenty of the functions in the program itself or 3rd party library
functions are probably not re-entrant safe and even if they are, having
code stomp over itself - eg if in the middle of writing a log message then a
signal is generated which tried to write a log message itself - is a very
poor way to write code.

On Mon, 6 Jan 2025 17:53:20 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wibbled:
>Muttley@dastardlyhq.org wrote:
>> Unix signals should only be used to set flags that are then read later. Doing
>
>> anything complicated in a signal handler is asking for trouble as you have
>> no idea where the program was when the signal occured and there can be all
>> sorts of re-entrant issues or even deadlocks if using mutexes.
>
>That is what I have learned, too, but I cannot remember the
>source. Maybe one of Richard Stevens' UNIX books.
>
>I am no expert, but I guess if you need to do async programming
>on UNIX/Linux userspace, your best is to use POSIX Threads.

Agreed.

Lawrence D'Oliveiro , dans le message <vli2lj$1t3lt$8@dont-email.me>, a
écrit :
> Linux offers signalfd, so you can indeed use poll(2) in a thread to be
> woken up by any file descriptor, including a signal one (and that includes
> POSIX real-time signals).

Proving my point that you need to use poll() even when doing threads.

In article <vlip2c$24ccb$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>On Mon, 06 Jan 2025 16:46:56 GMT
>scott@slp53.sl.home (Scott Lurndal) wibbled:
>>Muttley@DastardlyHQ.org writes:
>>>On Mon, 06 Jan 2025 15:05:33 GMT
>>>scott@slp53.sl.home (Scott Lurndal) wibbled:
>>>>Muttley@DastardlyHQ.org writes:
>>>>>In Windows yes, which frankly is probably not a coincidence. Not so much
>>>>>in unix unless you're writing a GUI program.
>>>>
>>>>ASTs and unix signals have similar semantics. It's certainly possible to
>>>>use, for example, SIGIO in a similar manner to the VMS AST, where the
>>>>AST signals I/O completion and the AST handler initiates a subsequent
>>>>operation.
>>>
>>>Unix signals should only be used to set flags that are then read later.
>>
>>You're opinion is not widely shared. Note that the POSIX specification
>>carefully notes which interfaces are not signal-safe.
>
>ITYF it is VERY widely shared and having a signal safe API function is only
>step 2 - plenty of the functions in the program itself or 3rd party library
>functions are probably not re-entrant safe and even if they are, having
>code stomp over itself - eg if in the middle of writing a log message then a
>signal is generated which tried to write a log message itself - is a very
>poor way to write code.

So don't write code that way. It does not follow that the only
thing you can do in a signal handler is an some atomic flag
somewhere.

- Dan C.