The Buffer is to avoid allocations, not to work around a stateless Collator. This could be clarified perhaps.
On Mon, Jun 13, 2016 at 8:52 PM, Sugu Sougoumarane <sou...@google.com> wrote: > 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> wrote: >> >> On Mon, Jun 13, 2016 at 10:18 AM, roger peppe <rogp...@gmail.com> 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. >> 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.
