51–60 of 65 posts
Earlier quoted context omitted.
website owner here: odd, what configuration of firefox gives you that warning. When I connect with a recent OS X version, it seems to work okay.
Firefox on Windows here. Looks like it's getting the certificate for github, but throwing an error because your domain isn't listed in that certificate. https://imgur.com/a/UeXtC
Earlier quoted context omitted.
"Async-signal-safe" is a C concept (from the POSIX world where C is your interface to the system, and library calls vs. system calls are behind the abstraction layer), so it doesn't directly apply to Rust. But the underlying semantics of signals are simple to describe: you get interrupted at some instruction pointer and jump into a new function. You can do whatever you want provided you uphold safety, correctness, li…
Note that the lock is a red herring. A single threaded malloc wouldn't be async signal safe either unless explicitly designed to be so which is hard. In fact anything that touches mutable state, including thread local state is a problem.
Earlier quoted context omitted.
Firefox on Windows here. Looks like it's getting the certificate for github, but throwing an error because your domain isn't listed in that certificate. https://imgur.com/a/UeXtC
Yeah, it's not set up for https. Do you see the same thing with http://www.jonathanturner.org/ ?
I often use make to run jobs in parallel. It is nice to be able to continue after an error or breakage, especially when working with large workloads.
GNU Parallel has --joblog and can continue from where it left off or retry all failed jobs again.
Not comparing it with the simpler, better moreutils parallel is really unfair.
Earlier quoted context omitted.
The only thing you can do from a signal handler is flipping a static and only one signal handler can be set. Good luck making this reusable. In fact, I challenge you to solve the problem "spawn process; waitpid for 15 seconds; otherwise kill hard" in Rust (or C++ if you feel like) on POSIX once with threads and once without threads by sticking to what's permitted in the standard and so that multiple processes can be…
> The only thing you can do from a signal handler is flipping a static and only one signal handler can be set. This is false, you can call any async signal safe function. Incidentally write is one of them. Another trick is the close-on-exit pipe.
Which malloc() is not. Anything that might internally allocate is out of the question. The list of functions that are safe to call in C alone is very limited and even then the question of errno arises.
Earlier quoted context omitted.
The only thing you can do from a signal handler is flipping a static and only one signal handler can be set. Good luck making this reusable. In fact, I challenge you to solve the problem "spawn process; waitpid for 15 seconds; otherwise kill hard" in Rust (or C++ if you feel like) on POSIX once with threads and once without threads by sticking to what's permitted in the standard and so that multiple processes can be…
Here's a sound implementation with signals using only the Rust standard library and POSIX, no threads: https://play.rust-lang.org/?gist=ba4802a59f462cb8bce0c1bac92... It would be significantly simpler with sigwaitinfo() if you didn't care to do a real select loop, but I assume most programs want a real select (or poll/epoll/whatever) loop.
Earlier quoted context omitted.
Note that the lock is a red herring. A single threaded malloc wouldn't be async signal safe either unless explicitly designed to be so which is hard. In fact anything that touches mutable state, including thread local state is a problem.
Yeah, good point. The weird part is that it almost introduces a new thread, in that it introduces a new flow of control (and, if you ask for it, a new stack), but it doesn't count as a new thread in all the usual ways, like thread-local variables or PIDs. So any code called from a signal handler must be "thread-safe", but that thread-safety cannot rely on assigning an identifier to the thread, because you're using th…
Worse: most signal handlers that do anything other than setting globals destroy errno in one way or another and when you go back the code that was interrupted has a good chance of malfunctioning.
Earlier quoted context omitted.
Here's a sound implementation with signals using only the Rust standard library and POSIX, no threads: https://play.rust-lang.org/?gist=ba4802a59f462cb8bce0c1bac92... It would be significantly simpler with sigwaitinfo() if you didn't care to do a real select loop, but I assume most programs want a real select (or poll/epoll/whatever) loop.
Which proves my point. It's messy, inefficient and now you wrote code which is not composable as you have a global (and the only) signal handler.
It's not composable, but it's not impossible to work around that if you can assume non-POSIX. Platforms with kqueue just get this right because kqueue can wait for processes. Linux will let you use a different signal to alert for process completion, so pick one of the realtime signals (which is its own game of global namespaces, but hey), and library code that uses SIGCHLD won't be affected. So that's Linux, OS X, and the BSDs. I don't know of a good workaround for Solaris.
A POSIX-compliant way that makes this more composable is to make a single, dummy process to be a process group, setpgid() all your actual children into that process group, and have that process spend its time doing waitpid(0, WNOHANG) and sending you notifications over a pipe or something. That is higher overhead, but my guess is that scales better for many child processes (O(1) extra processes vs. O(n) extra threads).
Earlier quoted context omitted.
Which proves my point. It's messy, inefficient and now you wrote code which is not composable as you have a global (and the only) signal handler.
I don't think it's less efficient than threads (but someone should test it!). It scales better. It's not composable, but it's not impossible to work around that if you can assume non-POSIX. Platforms with kqueue just get this right because kqueue can wait for processes. Linux will let you use a different signal to alert for process completion, so pick one of the realtime signals (which is its own game of global names…
In that case you are pretty much limited to polling on the thing (unless apparently you use kqueue, did not know you can wait on process events).