FAQ
Also: it's not that sync.Locker requires a pointer receiver. It's that
(*sync.Mutex).Lock() and Unlock() do.

If you really want to have a pointer Mutex in objects that are meant to be
copied, you're not going to be able to do it without the cumbersome new in
each literal. The standard way to deal with this is to make a function that
constructs instances of the object.
On Thursday, August 27, 2015 at 4:41:57 PM UTC-7, James Aguilar wrote:

Hrm. I think you're going to want to be passing around pointers of this
thing anyway. Otherwise, you'll effectively have copies of the thing
running around, all being protected by the same Mutex. Like so:
http://play.golang.org/p/VvKXDXr5eQ
On Thursday, August 27, 2015 at 4:35:12 PM UTC-7, Gbr wrote:

No, unfortunately. If you make sync.Mutex a direct embedded field (as
opposed to a pointer field), you loose implementation of Y -- sync.Locker
requires a pointer receiver.
On Thursday, August 27, 2015 at 4:24:39 PM UTC-7, James Aguilar wrote:

type X struct {
Value int
sync.Mutex
}

If I understand you correctly, you want to avoid having to type out the
"new" for the mutex each time you use the type literal. This should work,
shouldn't it?
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 19 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 27, '15 at 10:48p
activeAug 29, '15 at 1:56a
posts19
users7
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase