On Sat, 25 Jun 2016, 6:27 AM Nick Pavlica <lini...@gmail.com> wrote: > > > On Thursday, June 23, 2016 at 6:44:22 PM UTC-6, Caleb Spare wrote: >> >> > To see if the the >> > race detector would find this potential bug for me, I ran the code with >> the >> > mutex(s) commented out with the -race flag on and didn't get a >> warning. >> >> Did you make some concurrent requests? The race detector only tells >> you about races that happen, so you need to excercise the concurrent >> code paths in some way (possibly in a test or by selectively turning >> on -race in a production-like environment). >> > > I just accessed the endpoint from multiple browsers, but no formal tests. > > >> >> A couple of general thoughts: >> >> (1) The primary way to know whether a library you're using will call >> your code concurrently from multiple goroutines is via documentation. >> The net/http documentation, for instance, explains that Serve creates >> a goroutine for each connection. Any other library you use should >> clearly explain this if it's the case. >> > > That makes sense, but seems to be a little fragile. For example, if the > lib wasn't originally concurrent, then is changed, it would be easy to get > into a bad situation. It makes me want to just wrap every variable in a > Mutex to be safe. I'm guessing that the pattern is to keep Go programs as > small as possible so you can track all the corner cases effectively in your > own mental model. >
I feel like it shouldn't necessarily matter if the lib will call your handlers concurrently or not. The focus should be on the fact that you are wanting to share global state within the body of that function. Shouldn't the answer be that you should avoid mutating global state without proper synchronization? I don't feel like you should need to run a tool to find out if it is calling your code concurrently. Rather just use best practices to write safer code in the first place. > >> (2) net/http and other server packages are a slightly unusual case -- >> there are many libraries that exist, but most don't call your code >> concurrently. (Even packages that invoke provided callbacks are >> themselves a minority.) If I use a package that, say, interfaces with >> a database or implements a graph algorithm, it would be quite strange >> if it used concurrently-invoked callbacks. >> > > As I ponder this; I wounder if some tooling could be added to the compiler > or an outside utility that would scan all the used libraries, and notify > you that the libraries/functions are concurrent. > > For example: > > -------------------------------------------------------------------------------------------------------- > go run --chk_concurrent mylib.go > > Notice: "net/http" calls concurrent operations on the Handle function. > > -------------------------------------------------------------------------------------------------------- > > Thanks again for the feedback! > --Nick > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
