5 ms·

What next? Job control signals?? :) (EDIT: How about tmux?) Anyways, this is fantastic. Finally, proper ssh functionality! This will encourage development

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 https://github.com/stedolan/jq (look in src/main.c)

tom_ 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
      Linux can do that as well, see SIGEV_THREAD.
      - quotemstr 8y ago
        Only for AIO, which few use.
        andreyv 8y ago
        You can spawn a thread manually and use the POSIX sigwait() function.
        quotemstr 8y ago
        That won't stop the process-wide registered signal handler working and it won't do anything about being able to reliably handle synchronous signals.
- cryptonector 8y ago
  Yes, of course signals are easily the worst thing in Unix, but job control is nice.
  - zvrba 8y ago
    It's already there: https://docs.microsoft.com/en-us/windows/desktop/ProcThread/job-objects 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 8y ago
      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 8y ago
        *with threads
        ygra 8y ago
        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 8y ago
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.

tom_ 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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 8y ago
    Linux can do that as well, see SIGEV_THREAD.
    - quotemstr 8y ago
      Only for AIO, which few use.
      - andreyv 8y ago
        You can spawn a thread manually and use the POSIX sigwait() function.
        quotemstr 8y ago
        That won't stop the process-wide registered signal handler working and it won't do anything about being able to reliably handle synchronous signals.
cryptonector 8y ago
Yes, of course signals are easily the worst thing in Unix, but job control is nice.
- zvrba 8y ago
  It's already there: https://docs.microsoft.com/en-us/windows/desktop/ProcThread/job-objects 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 8y ago
    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 8y ago
      *with threads
      - ygra 8y ago
        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 8y ago

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.