SC> I also have absolutely no idea what happens with signals if you run
SC> dd under Cygwin on Windows.

I'd guess theres no equivelant.

---------------
user <candycane> is generated from /dev/urandom

.... return ENOMEM;
___ MultiMail/Linux v0.52

On 9/5/2023 3:31 PM, candycane wrote:
> SC> I also have absolutely no idea what happens with signals if you run
> SC> dd under Cygwin on Windows.
>
> I'd guess theres no equivelant.

Cygwin apparently does emulate signals.

https://cygwin.com/cygwin-ug-net/highlights.html

<quote>
Signals

When a Cygwin process starts, the library starts a secondary thread for
use in signal handling. This thread waits for Windows events used to
pass signals to the process. When a process notices it has a signal, it
scans its signal bitmask and handles the signal in the appropriate fashion.

Several complications in the implementation arise from the fact that the
signal handler operates in the same address space as the executing
program. The immediate consequence is that Cygwin system functions are
interruptible unless special care is taken to avoid this. We go to some
lengths to prevent the sig_send function that sends signals from being
interrupted. In the case of a process sending a signal to another
process, we place a mutex around sig_send such that sig_send will not be
interrupted until it has completely finished sending the signal.

In the case of a process sending itself a signal, we use a separate
semaphore/event pair instead of the mutex. sig_send starts by resetting
the event and incrementing the semaphore that flags the signal handler
to process the signal. After the signal is processed, the signal handler
signals the event that it is done. This process keeps intraprocess
signals synchronous, as required by POSIX.

Most standard UNIX signals are provided. Job control works as expected
in shells that support it.
</quote>

Arne