[cryptonector]

What next? Job control signals?? :) (EDIT: How about tmux?)

Anyways, this is fantastic. Finally, proper ssh functionality!

This will encourage development of console (text-oriented) apps for Windows, which I hope will be much simpler. Interfacing with the console can be really difficult if you're coming from *nix. Ideally all the WIN32-specific code in, e.g., jq[0], could be ripped out.

[0] https://github.com/stedolan/jq (look in src/main.c)

[tom_]

The lack of signals in Windows is the very opposite of a flaw! - Windows has just never pretended you can get away without a message loop.

[quotemstr]

Windows does have signals! It just splits them into a few facilities. POSIX "synchronous" signals correspond to SEH exceptions and can be handled roughly the same way --- except that signals have process global handlers and Windows has thread-local ones, because the glibc people are sticks in the mud and are hostile to any attempt to make signals suck less.

For asynchronous signals, like SIGINT, Windows create a new thread out of thin air to deliver your app a notification. That's not really all that much better than a signal from a concurrency perspective.

Windows even has APCs, which are like regular signals that are delivered only at explicit system call boundaries.

Every operating system needs some mechanism to tell a process to do something. Windows has evolved an approach that isn't all that different from Unix signal handling.

[cryptonector]

Spawning a new thread to handle a signal is much better than preemption: you then have no concerns about async-signal-safety that aren't plain old thread-safety concerns. I'd much rather have thread-safety constraints than async-signal-safety constraints.

[quotemstr]

Sort of. At least you can mask signals. I agree that threads are probably better overall, but I don't think it's a huge difference.

[Vogtinator]

Linux can do that as well, see SIGEV_THREAD.

[quotemstr]

Only for AIO, which few use.

[andreyv]

You can spawn a thread manually and use the POSIX sigwait() function.

[cryptonector]

Yes, of course signals are easily the worst thing in Unix, but job control is nice.

[zvrba]

It's already there: https://docs.microsoft.com/en-us/windows/desktop/ProcThread/...

You can set various limits, though I haven't seen functions to stop/resume a job.

[ygra]

You can suspend and resume threads, so if you model your jobs with processes that could be used for that, I guess.

[loa-in-backup]

*with threads

[ygra]

Processes. A quick skim of the documentation linked by the person I answered suggests that processes can be associated with a job object, but threads cannot. But a process cannot really be suspended directly, except by suspending all its threads.

[skrebbel]

First, tmux works fine in WSL. Secondly, if you like both tmux and Windows, there's a fair chance you'll like ConEmu's split panel facility even better. It's basically tmux, but more "windowsy". ConEmu is spectacular.