I think the Go norm of assuming that things are not thread-safe unless stated otherwise makes sense. In this particular case, the function required the caller to provide a buffer to fill. That gave the impression that the Collator was stateless. It's possible that others could also get misled.
On Monday, June 13, 2016 at 9:49:14 AM UTC-7, Michael Jones wrote: > > Hmm… Not sure about repetitavely saying that specific data should not be > accessed concurrently. Better may be to say that nothing (generally) should > be accessed concurrently; that concurrency is accessed by a few special > mechanisms that hide the concurrency behind a reasoned, reliable facade of > sequential operation. This is already said in several ways so maybe rather > than saying it for each data item and each API element, we should encourage > self-study in the literature. > > Perhaps there should be a “The Go Mindset” document for background on the > intellectual heritage behind Go’s concepts in concurrency. The history is > essential and it is sobering to think that not everyone is intimately > familiar with it. When I read the Go documentation, several computer > science heroes and their original papers are on my mind: > > C. A. R. Hoare (“Tony Hoare”), inventor of Quicksort and essential to Go, > the expositor of Communicating Sequential Processes, with collaboration by > Edsger Dijkstra: > > Communicating Sequential Processes (this is THE paper of all papers) > http://spinroot.com/courses/summer/Papers/hoare_1978.pdf > > A Model for Communicating Sequential Processes > http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1013&context=compsciwp > > > Per Brinch Hansen wrote an early book (1977), “The Architecture of > Concurrent Programs” that was important to me as a tutor. It teaches the > design complex concurrent systems as a loosely coupled ensemble of > sequential components connected safely by a minimal rigorous infrastructure > of *channels*, *send*, *receive*, and *select*. > > Architecture of Concurrent Programs (Google Book Search > <https://books.google.com/books?id=0KVQAAAAMAAJ&q=The+Architecture+of+Concurrent+Programs&dq=The+Architecture+of+Concurrent+Programs&hl=en&sa=X&ved=0ahUKEwiJ08yIs6XNAhUHfVIKHQPhAgAQ6AEIHjAA> > ) > Per Brinch Hansen > > The Origin of Concurrent Programming (Google Book Search > <https://books.google.com/books?id=c__lBwAAQBAJ&pg=PA3&dq=The+Origin+of+Concurrent+Programming&hl=en&sa=X&ved=0ahUKEwiCkv3Ps6XNAhVEXlIKHeDKBRUQ6AEIHjAA#v=onepage&q=The%20Origin%20of%20Concurrent%20Programming&f=false>) > > RECENT! > Per Brinch Hansen > > > These are the fundamental technical preparation to approach Go’s > concurrency concepts. It is helpful to read them not only for the insights > but also for the confusions. (Things murky to brilliant people are often > the “X” in a treasure map, with Euclid’s fifth postulate being the ultimate > example.) > > Another great "background for Go” text is a book by a friend of mine, Dr. > Fred Brooks of UNC and formerly of IBM. He is famously the author of The > Mythical Man Month but his magnum opus for me is the book, The Design of > Design: Essays from a Computer Scientist. There is no better book on > design—or rather, the science of meta design—in the world. The closest > rivals would be books on city design and urban architecture. > > The Design of Design: Essays from a Computer Scientist (Google Book Search > <https://books.google.com/books?id=0qG4TQi-e-4C&printsec=frontcover&dq=fred+brooks+design&hl=en&sa=X&ved=0ahUKEwjRjK2RtaXNAhVUMFIKHRN9BzYQ6AEIHjAA#v=onepage&q=fred%20brooks%20design&f=false> > ) > Frederick P. Brooks Jr. > > > One lesson from Dr. Brooks is the notion that “total design” leads to > efficient solutions but rigid systems not well suited to change while > “loose design” anticipates change, extension, and revision. (I am > paraphrasing here but the ideas are his.) Examples of loose design might be > LEGO with modular parts or in the Go context, channels and garbage > collection which together make “send and forget” possible, the pair of > which makes an arbitrary graph of independent communicating processes > workable and in fact, generally desirable over a carefully conceived > asynchronous program, such as a cleverly tuned game engine. > > Perhaps a list of references and suggestions of lessons to be learned > would be good as a link from the Go website. > > Michael > > On Jun 13, 2016, at 8:43 AM, Sam Whited <s...@samwhited.com <javascript:>> > wrote: > > On Mon, Jun 13, 2016 at 10:18 AM, roger peppe <rogp...@gmail.com > <javascript:>> wrote: > > No Go type should be assumed to be safe for concurrent use unless > explicitly > documented otherwise (or obviously safe, for some definition of "obvious"). > > > I think that's what I said? Either way it seems like there's no harm > in being explicit. > > —Sam > > -- > Sam Whited > pub 4096R/54083AE104EA7AD3 > https://blog.samwhited.com > > -- > 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...@googlegroups.com <javascript:>. > 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.
