Jesse Storimer writes about Ruby, threads, the GIL and Unix processes, and wrote the book Working With Unix Processes.
HN commenters point to his GIL series as a detailed explanation and recall his Unix processes book fondly; his stderr vs stdout post is cited too.
I would say that developer tools are a terrible market for that reason. Information products (screencasts, books, etc) can be extremely successful in the same market. Examples abound, including patio11's marketing training[1], egghead.io[2] for AngularJS training, Peepcode[3], Railscasts[4], and various other ebooks [5][6][7].
Most developers that I know have two common traits that make info products an easier sell. First, they're innately curious about their field. Second, they have access to a company credit card that will happily pay for training materials.
[1]: https://training.kalzumeus.com
[2]: http://egghead.io
[3]: https://peepcode.com
[4]: http://railscasts.com/pro
[5]: http://www.nathanbarry.com/authority
[6]: https://www.petekeen.net/mastering-modern-payments
[7]: http://www.jstorimer.com/products/working-with-ruby-threads
> you're talking about one thread per core, not one thread per unit of work?
Yes, a thread pool, consisting of one thread per core/computing unit. The units of work are then scheduled between the threads. Units of work here being some kind of IO, e.g. servicing HTTP requests.
> but if you want to spin up a few hundred thousand of them...
Hm. Thought there was a limit for work that can be done concurrently by the CPU, based on the number of cores/hyper-threads available. Found this on threads and IO performance [1], it seems to make the same point.
What kind of work load is common to spread over so many threads (on the same machine)? Does the OS switch efficiently between hundred of threads on regular CPUs? Genuinely interested.
1: https://www.jstorimer.com/blogs/workingwithcode/7970125-how-many-threads-is-too-many
Maybe just convention? It's standard practice to use stdout for directly interacting with a user and stderr for log/error type messages. You can redirect stderr to a file to get all of your log messages, but keep stdout available for interacting with the user. Super useful to separate meta-messages out in this manner.
Here's a good blog post with more info on stderr for those interested: https://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout
Great question!
Reminds me of Jesse Storimer http://jstorimer.com/ who originally published 'Working With Unix Processes' independently which subsequently got picked up by The Pragmatic Programmers: http://pragprog.com/book/jsunix/working-with-unix-processes
Currently working on some books myself.
This 3 parts series from 2013 explains in details how the GIL works http://www.jstorimer.com/blogs/workingwithcode/8085491-nobody-understands-the-gil
Disclaimer: it's linked in the omniref.com page too.
This looks interesting. It reminds me of book that explained the details behind dealing with unix processes using ruby. I really liked it: http://www.jstorimer.com/products/working-with-unix-processes