11–20 of 31 posts
I can't read the article but hopefully it does not ironically present advice on writing webservers. There is really little excuse for a web server to buckle under pressure these days - hackernews sends a spike of traffic but not enough to kill even a moderately spec'ed server.
Simple example for Java: do not create executorservice instances inside of a library, but allow client code to pass them.
Ayende wrote much better than me long time ago https://ayende.com/blog/159201/multi-threaded-design-guideli...
The blog seems sadly unable to tolerate the load. I don't see an archived version of the post anywhere either. If I had to have a guess what it says, it's probably something along the lines of: * Don't require users of your API to start goroutines to use your API correctly. If Goroutines need to be started for your API to work, start them in an init function, on first use, or via some other mechanism. * If possible,…
Doesn't the native net/http server spin up a goroutine for every request? Edit: See line 2927 at https://golang.org/src/net/http/server.go
Request handlers are a bit of a special case too, in that they are a framework for dispatching tasks to be worked on; what is main() for a command line program is the request handler for a webserver. It seems fair that there is some concurrency coordination happening at the top level.
"threads" (goroutines) and channels are the new gotos. They tend to make a codebase more difficult to reason about. The more you add, the more you tend to get spooky action at a distance.
"threads" (goroutines) and channels are the new gotos. They tend to make a codebase more difficult to reason about. The more you add, the more you tend to get spooky action at a distance.
Many alternatives to channels (mutexes, atomics, semaphores, condition variables) have just as much if not more chance of turning the codebase into a mess. But yes I agree that if performance-wise you can handle being single-threaded, then do that, because it's much simpler.
"threads" (goroutines) and channels are the new gotos. They tend to make a codebase more difficult to reason about. The more you add, the more you tend to get spooky action at a distance.
These are hardly new concepts, nor are there any more appropriate mechanisms for modeling dependencies between multiple concurrent actors. If anything, the traditional shared memory nightmare has proven to be the goto in the room.
"threads" (goroutines) and channels are the new gotos. They tend to make a codebase more difficult to reason about. The more you add, the more you tend to get spooky action at a distance.
Is this still the case? How does modern Go handle operations which require kernel threads?
Some operations can use green threads, while others need kernel threads. Last I tried (~2015) Go would spawn unlimited kernel threads, so function callers had to know whether a call required a kernel thread or not, and rate-limit appropriately. Is this still the case? How does modern Go handle operations which require kernel threads?