Re: [go-nuts] An old problem: lack of priority select cases

[Albert Tedja]

This is something I ran into a while back, and made a library for it, 
though, I prefer not to spam the mailing list.  Feel free to send me a dm 
and I'll send you a github link if you are interested.

On Sunday, September 1, 2019 at 3:02:52 AM UTC-7, T L wrote:
>
>
>
> On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wrote:
>>
>>
>>
>> On Sat, 31 Aug 2019 at 10:02, T L  wrote:
>>
>>>
>>>
>>> On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:



 On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>
> The reason you're wanting priority select is because you are shutting 
> down the data channel preemptively, but you can wait for an 
> acknowledgement 
> from the run goroutine instead:
>
> https://play.golang.org/p/qSWluYy4ifl
>
>
 Your solution is clever. The Close method can be called multiple time 
 safely.
 Is there such a beautiful solution for multiple senders?
  

>>>
>>> Translating a multi-senders problem to a single sender problem is the 
>>> only way I can get:
>>> https://play.golang.org/p/dAppUxP96g4
>>>
>>
>> The answer really depends on what you're actually trying to do. What are 
>> the multiple senders? What's the actual problem you're trying to solve?
>>
>> I'd fairly sure you'll be able do what you want without requiring a 
>> prioritised select, which is what this thread was about.
>>
>>   cheers,
>> rog.
>>
>>
> Yes, there are ways to handle the problem of uncertain number of senders, 
> but there are no simple ways.
> A mechanism must be designed to avoid any sender writing to a closed 
> channel.
>  
>
>>  
>>>

> On Wed, 28 Aug 2019 at 18:06, T L  wrote:
>
>> The old thread: 
>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>
>> Go channels are flexible, but in practice, I often encountered some 
>> situations in which channel are hard to use.
>> Given an example:
>>
>> import "math/rand"
>>
>> type Producer struct {
>> data   chan int
>> closed chan struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p :=  {
>> data:   make(chan int),
>> closed: make(chan struct{}),
>> }
>> 
>> go p.run()
>> 
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance 
>> order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a 
>> higher priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a 
>> channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much 
>> tedious to implement the code
>> satisfying the above listed requirements. The final implementation is 
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
>> -- 
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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 golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/e239c78f-61fc-4238-aa5d-f776cb9aec03%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group 

[go-nuts] By passing go type check when performing bitwise operator

[Albert Tedja]

 I am trying to perform some bitwise operators, but Go is not letting me 
because the mask is an uint and the values are int. Setting the mask to int 
will break the code since I am shifting bits right and left and prefer the 
prefix 0 when shifting right, and if I am not mistaken, Go does not have 
>>>.



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a211253c-eec1-4efb-8f4c-5e94f04e6681%40googlegroups.com.

[go-nuts] Re: Closed channel vs nil channel when writing

[Albert Tedja]

No such thing as a 'nil channel'. You are merely setting a variable to nil, 
regardless what the previous content is.

It's just that Go allows you to receive from a nil variable if that 
variable's type is a channel, in which case it blocks forever.



On Sunday, September 1, 2019 at 9:03:58 AM UTC-7, clement auger wrote:
>
> hi,
>
> I am looking for further details and explanations about the various 
> behaviors
> associated with closed Vs nil channels.
>
> I already read 
> https://stackoverflow.com/questions/43616434/closed-channel-vs-nil-channel
> and other publications such as 
>
> https://medium.com/justforfunc/why-are-there-nil-channels-in-go-9877cc0b2308 
> (for example)
>
> They repeat the explanation of the behaviors the programmer will have to 
> deal with, 
> however they don't really explain the internal, nor the reasons of the 
> differences
> found with this example https://play.golang.org/p/4LuZ32gzWbu when 
> closing or niling the channel
>
> I wonder under which case it is useful to panic on write, Vs branching to 
> a default case within a select.
> Said differently what is the advantage of a panic Vs a syntax like ok := 
> mychan <- myval; if !ok { return "not wrote" }
>
> This happened while reading at T.L. in 
> https://groups.google.com/forum/#!topic/golang-nuts/lEKehHH7kZY
>
> *Yes, there are ways to handle the problem of uncertain number of senders, 
> but there are no simple ways.*
> *A mechanism must be designed to avoid any sender writing to a closed 
> channel.*
>
> thanks for anyone able to provide some details.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/758e9c07-648f-4d29-8035-37e1e0d1dba4%40googlegroups.com.

[go-nuts] net/http Server Shutdown does not free up the port upon return

[Albert Tedja]

net/http's Shutdown() does not free up the port upon return, or rather it 
seems a bit undefined how long it takes for the port to be reusable again.

server := {
Addr: fmt.Sprintf(":9000"),
}
go func() {
fmt.Println("hosting...")
err := server.ListenAndServe()
}()
time.Sleep(1 * time.Second)

fmt.Println("closing")
err := server.Shutdown(nil)
fmt.Println("shutdown error", err)

fmt.Println("hosting again...")
err = server.ListenAndServe()
fmt.Println("host again err", err)



The code above, for example, sometimes successfully hosting the http server 
twice, but sometimes, the second one fails with "address already in use" 
error

$ go run main.go 
hosting...
closing
shutdown error 
hosting again...
// This is okay

$ go run main.go 
hosting...
closing
shutdown error 
hosting again...
host again err listen tcp :9000: bind: address already in use

My question is, is this a bug, or an expected undetermined behavior? If 
it's the latter, how can I safely make sure that Shutdown() completely 
frees up the port used?

-- 
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.

[go-nuts] Re: is this safe?

[Albert Tedja]

You need to swap elements if you want to remove them from list while 
iterating it. There are two ways to do this:

First: iterate backward. This will however, will change the order of 
unremoved elements.

Second: iterate forward, and will preserve the order of the unremoved 
elements.

https://play.golang.org/p/x2NMixEPI5

-- 
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.

[go-nuts] Re: My trouble of local package referencing

[Albert Tedja]

Yes, it's a debatable subject within the Go community. See this blog for 
example:

https://medium.com/@c9s/golang-the-annoying-remote-import-path-c6c7e76517e5

There are some tricks you can do using a different git remote, `git remote 
add myfork github.com/yourfork/project`

Then when you push, you call `git push myfork master`

I am not too keen of using this trick. It's kind of like banging your 
computer case to fix it. Go paths and dependency management has been broken 
if you use it in the manner not intended by its original design, and they 
are fixing it right now.

-- 
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.

[go-nuts] Re: golang and http2

[Albert Tedja]

Thank you for the links.

I am still somewhat disappointed that the http/2 protocol would enforce a 
certain configuration. I understand the necessity of secure connections, 
but that's should be left as an option to the developers.

If browsers want to strictly use TLS, that's fine because it's consumer 
facing, but at least Go should enable http/2 over non-TLS. We are engineers 
here, we should know the difference.


On Wednesday, November 15, 2017 at 12:05:41 PM UTC-8, Howard C. Shaw III 
wrote:
>
> See
> https://github.com/golang/go/issues/14141 - for discussion of the issue; 
> and 
> https://github.com/hkwi/h2c for a way to use the in 
> stdlib-but-not-linked-together support for h2c (http/2 over non-TLS).
>
> Howard
>

-- 
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.

[go-nuts] golang and http2

[Albert Tedja]

I am reading Golang's support for HTTP2, and it seems it is only enabled by 
default if you use https

https://go-review.googlesource.com/c/go/+/15828

My questions are:
1. Does this mean I have to use ListenAndServeTLS() to enable http2 and if 
not, it will fallback to HTTP1.1?
2. Can I explicitly enable HTTP1.1 with https?
3. Can I explicitly enable HTTP2 without https?
I am asking because I might need to have a LB, or reverse proxy like nginx, 
in front of the app that's handling the SSL handshake.
If this is how my servers are set up, and HTTP2 is only enabled if TLS is 
enabled, does this mean I am stuck with HTTP1.1 unless I copy the 
certificate to all of instances?

-- 
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.

Re: [go-nuts] Writing your own Context, making sure it's compatible with context.Context

[Albert Tedja]

> Can you just have a field of your Context type be a value of type 
> context.Context? 
>
> Ian 
>

I managed to do this eventually. The confusion was that my library has 
multiple types of contexts and they need to be stacked in any particular 
order. So at first, the values from previous (parent) contexts did not seem 
to transfer well to the child contexts. When looking at the context.Context 
source code to learn how it does that, I was surprised to learn that it 
propagates those cancellation signals down to its children manually, which 
is yucky.

What I ended up doing is create another Context interface for my package 
that has all the functions I need. Create a parent struct that implements 
those functions with empty features. Then each feature context can overload 
those functions as needed.

package yourpackage

import "context"

type Context interface{
context.Context
FeatureX() *X
FeatureY() *Y
FeatureZ() *Z
}

type BasicContext struct {
context.Context
}

func (ctx *BasicContext) FeatureX() *X {
return nil;
}

func WithBasicContext(parent context.Context) Context {
return {Context: parent}
}

type featureXContext struct {
Context
x *X
}

func (ctx *featureXContext) FeatureX() *X {
return ctx.x
}

func WithFeatureX(parent Context, x *X) Context {
return {Context: parent, x: x}
}

It seems to be functioning as expected, and compatible with the other 
contexts like WithDeadline or WithTimeout.

-- 
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.

[go-nuts] Writing your own Context, making sure it's compatible with context.Context

[Albert Tedja]

I am writing a library that could use the benefit of context, but I also 
want to add additional functionalities to the context my library using, 
while keeping the same golang idiom of using With*() to create a new 
context based off its parent.

At first, it seems that all I need to do is to satisfy the context.Context 
interface, but as I look deeper into the context.go source code 
(https://golang.org/src/context/context.go), it looks like that I wouldn't 
be able to benefit from parent's context, unless I reimplement some of the 
original context.Context features, in particular its cancelCtx.

For example, the code WithDeadline() creates a context with a deadline, 
which is really just a timerCtx, whose parent is cancelCtx. The context 
package also has this function called "propagateCancel()" which worries me 
a bit as it looks like the parent context maintains a list of its children.

So, if I want to create a new context with an additional feature, let's say 
WithFeatureX(context.Context, X), I cannot safely create a FeatureContext 
struct that can inherit from any previous contexts (possibly created from 
WithDeadline/WithCancel/WithTimeout) unless I also do the same thing as 
what propagateCancel() is doing. The parent context wouldn't know about the 
existence of FeatureContext unless I also duplicate the propagateCancel to 
include itself as a child.  In other words, the relationship between the 
parent context and its children is hard-coded in the context package.

My goal is to allow users of my library to specify their own context, 
either from Background() if they want just the basic, or WithTimeout() or 
WithCancel(), and then pass their context to library's own custom contexts 
WithFeatureX() or WithFeatureY() to add additional features, yet still 
retain its original parent's ability, whatever it is. It seems to me this 
is not possible without a lot of work and possibly access to the context 
package private functions.

Could you guys please let me know if my analysis is correct that 
context.Context is not really designed for this purpose? Or am I just 
simply wrong and overlooking something obvious?

Thanks!

-- 
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.

Re: [go-nuts] A way to detect closed channel

[Albert Tedja]

That makes sense.  If multiple goroutines are calling that select block, 
one or more could be attempting to close it.

Okay, nevermind then.

-- 
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.

[go-nuts] Re: A way to detect closed channel

[Albert Tedja]

Assuming of course, that the channel is only intended to send closed signal 
to other goroutines, rather than transporting meaningful data.

On Monday, November 6, 2017 at 4:59:51 PM UTC-8, Albert Tedja wrote:
>
> So, I just found out that closed channels always yield the zero value. 
> That means, a closed channel inside a select statement seems to always be 
> guaranteed to be executed.
>
> Since closing an already closed channel creates a panic, does this mean 
> then I can do this to make sure that the channel is closed only once?
>
>
> select {
> case <- closedchan:
> default:
> close(closedchan)
> }
>
>
>
> Golang playground: https://play.golang.org/p/LSrTh0HC2K
>
> It seems to work. Just want to confirm here before start doing this 
> everywhere in my code.
>

-- 
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.

[go-nuts] A way to detect closed channel

[Albert Tedja]

So, I just found out that closed channels always yield the zero value. That 
means, a closed channel inside a select statement seems to always be 
guaranteed to be executed.

Since closing an already closed channel creates a panic, does this mean 
then I can do this to make sure that the channel is closed only once?


select {
case <- closedchan:
default:
close(closedchan)
}



Golang playground: https://play.golang.org/p/LSrTh0HC2K

It seems to work. Just want to confirm here before start doing this 
everywhere in my code.

-- 
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.

[go-nuts] Re: Writing a non-blocking thread-safe buffer

[Albert Tedja]

I don't think using separate write/read channels do anything much here.  If 
you are concerned goroutines reading the channel somehow slowing down the 
writes, you already have a goroutine that's doing the transfer on the other 
end.



On Friday, April 7, 2017 at 8:36:14 AM UTC-7, Eno Compton wrote:
>
> Hi All,
>
> I'm trying to write a non-blocking thread-safe buffer for use in a high 
> throughput system. In short, I want to create a buffer that decouples the 
> speed of writes from that of reads. 
>
> For a first attempt, using channels in the implementation seems best. Here 
> is a link  to the current 
> implementation. I have a write channel and a buffered read channel. As an 
> intermediary between the two channels, I spin off a goroutine on 
> initialization of the buffer which constantly pulls values off the write 
> channel and attempts to put them on to the read channel. If the read 
> channel is full, I discard a value from the read channel before inserting 
> the new value.
>
> This implementation works. What I seek to do now is improve the throughput 
> of the buffer. I understand doing so requires proper benchmarking and 
> measuring. What I'm curious about though is the experience of others on 
> this list. In systems which require high throughput, am I best suited 
> sticking with channels? Would atomics be an appropriate design choice? What 
> about mutexes?
>
> Forgive me if this question seems naive. I'm new to Go and am still 
> developing a sense for the language.
>
> Thanks,
>
> Eno
>

-- 
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.

Re: [go-nuts] dep: Roadmap for merging into the toolchain

[Albert Tedja]

I was using godeps before and now govendor, and never felt 100% happy with 
either one.  I have some feedback of how I think the package management 
tool should work from the developer perspective, and here some features 
that I think is crucial.

1.  Standardize the package file.  With govendor, this is 
vendor/vendor.json.  This is great, but I want to commit vendor/vendor.json 
to repo, but not the vendor folder.  I had to do some `git add -f`, a bit 
yucky.  Just standardize it, something like dep.json, or perhaps Depfile.  
Doesn't matter the filename, just standardize it, and please don't put it 
under the vendor folder.

2. I want to specify which branch or which tag or which sha revision of my 
dependencies.  Do not let this process to be automatic unless a version is 
not specified in which case it should be the latest dep can acquire.  It is 
frustrating when it pulls the wrong one.

3. I want to update my vendor folder, and it should use the Depfile as the 
authoritative source of what versions should be downloaded.  Not the 
$GOPATH!  Package management tool should move away from relying $GOPATH/src 
as its authoritative source.  My $GOPATH/src contains versions of code that 
could be in development, months old, and what not.  Let me control my 
$GOPATH with `go get`, while dep can use other ways to pull code directly 
to the vendor folder without messing with the $GOPATH.  $GOPATH is the 
development workspace.  vendor folder should have the stable versions for 
that particular project.  I had a time when govendor pulled a version from 
my GOPATH. Ugh.

4. Packages/libraries should be allowed to have its own Depfile.  I have 
heard/read somewhere that somehow this is discouraged by the Go community.  
I am not sure why.  I thought it would simplify the process by a whole lot 
from development perspective that you reuse other people code.  Put the 
responsibility to the library maintainers to maintain up-to-date Depfile.  
And from dependency management, you don't have to scan the entire source 
files to find the dependency tree.  In case of version conflict, such as 
package A depends on C.v1, and package B depends on C.v2, just pick one 
(latest) version but WARNS the user.  If there is a compile error, it won't 
build anyway.  I feel like the only way to resolve this is to actually 
overwrite the import statements.

5. Since packages is allowed to have its own Depfile, then each project 
should only be concerned with its direct dependencies, not the complete 
tree.

6. Let Depfile be user specified, not something that dep automatically 
generates. I kinda like the way Gemfile and Gemfile.lock works.  Gemfile is 
user specified, while Gemfile.lock is automatically generated and contains 
the complete dependency tree. You commit Depfile to repo, but you do not 
commit Depfile.lock to repo.

Having said that, I normally approach problems from end-user perspective 
and start there. Assuming `dep` is the command here, the following commands 
are possibly some that I would use:
`dep init` - Read Depfile, checks out direct dependencies to vendor folder, 
figure out the entire tree, create Depfile.lock, and fill the vendor folder 
with the complete dependency tree, while also stripping out unnecessary 
files like tests, .gitignores, etc from them.
`dep update %package_name%` - Updates Depfile.lock for that particular 
package only to use the latest version (and of course its dependencies), 
iff the package is specified on Depfile with an unspecified version.  If 
not specified on Depfile, just throw the error.
`dep build` - Build the project using the vendor folder ONLY. This is to 
make sure that your app can be shipped to somewhere else with a different 
environment.  I can totally see somebody has github.com/foo somewhere in 
their GOPATH, but not specified on Depfile, and just says 'it works on my 
computer?'

And...that's it.  I don't understand why all the dependency tools have 
these dozens of commands that 99% of time you don't end up using.

I would rather have tools that is plain but consistent and has expected 
behaviors, than attempt to be smart but failed.

Something nice:
Allow zipping up the packages in the vendor folder so I can actually check 
the zips into the repo.  While this can be counterintuitive, but recently I 
have had a problem where I had to do a complete pull of my old project, and 
one of the dependencies had breaking changes.  I did not want to update my 
code to follow the breaking changes, and the package maintainer is bad at 
keeping track of branches and tags that there is virtually no way for me to 
go back in time and find the version that is compatible.  To make matters 
worst, this library depends on 6 other libraries that all depend on each 
other, and all have breaking changes.  Yes, NP-complete problem.  I ended 
up writing my own.

This also would be nice for deploys.  If you can check in your entire 
dependency, instead of redownloading all code from 

[go-nuts] Re: Does sync.Cond call Lock() twice on the underlying Locker?

[Albert Tedja]

Ugh. It makes sense now. cond.L.Lock() gets called from the first 
goroutine, then immediately followed by another Lock() from the second.  
Therefore, in order to properly implement Lock(), it actually has to be 
blocking.

On Monday, March 13, 2017 at 4:35:04 PM UTC-7, dja...@gmail.com wrote:
>
>
>
> On Tuesday, March 14, 2017 at 12:10:31 AM UTC+2, Albert Tedja wrote:
>>
>> I am writing a custom Locker which does a check if Lock() is being called 
>> more than once and throws a panic if it does.
>> I tested it to see if I can use it with sync.Cond, and for the most part, 
>> it was running as intended, except once in a while
>> the panic check triggered.
>>
>> Here's the dumbed down version of what I am trying to do:
>>
>> https://play.golang.org/p/2tWqY221RM
>>
>> I cannot get it to reproduce on the Go Playground, but copy paste it to 
>> your local computer and see if you get it to panic.
>> Here's what I got:
>>
>> panic: Cannot lock twice
>> goroutine 5 [running]:
>> main.(*CustomLocker).Lock(0xc42000e2e0)
>> /.../go/src/github.com/test/custom_locker.go:18 +0xc9
>> main.main.func1(0xc4200142c0, 0xc42000e2f0, 0xc42000e2d0)
>> /.../go/src/github.com/test/custom_locker.go:42 +0x37
>> created by main.main
>> /.../go/src/github.com/test/custom_locker.go:50 +0x159
>> exit status 2
>>
>> I thought sync.Cond.Wait() should Unlock(), sleeps itself, then when 
>> awaken by Broadcast() try to Lock() again?
>>
>
> Hi,
>
> First, your custom Locker implements Locker interface, but does not lock 
> as it call Unlock at function return.
> Second, Locker main job is to call Lock() multiple times (from different 
> goroutines)
>
> Djadala
>

-- 
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.

[go-nuts] Re: Does sync.Cond call Lock() twice on the underlying Locker?

[Albert Tedja]

$ go version
go version go1.8 linux/amd64

-- 
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.

[go-nuts] Does sync.Cond call Lock() twice on the underlying Locker?

[Albert Tedja]

I am writing a custom Locker which does a check if Lock() is being called 
more than once and throws a panic if it does.
I tested it to see if I can use it with sync.Cond, and for the most part, 
it was running as intended, except once in a while
the panic check triggered.

Here's the dumbed down version of what I am trying to do:

https://play.golang.org/p/2tWqY221RM

I cannot get it to reproduce on the Go Playground, but copy paste it to 
your local computer and see if you get it to panic.
Here's what I got:

panic: Cannot lock twice
goroutine 5 [running]:
main.(*CustomLocker).Lock(0xc42000e2e0)
/.../go/src/github.com/test/custom_locker.go:18 +0xc9
main.main.func1(0xc4200142c0, 0xc42000e2f0, 0xc42000e2d0)
/.../go/src/github.com/test/custom_locker.go:42 +0x37
created by main.main
/.../go/src/github.com/test/custom_locker.go:50 +0x159
exit status 2

I thought sync.Cond.Wait() should Unlock(), sleeps itself, then when awaken 
by Broadcast() try to Lock() again?

-- 
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.

Re: [go-nuts] thread safety of map when each goroutine access a different key

[Albert Tedja]

Great. Thanks! Looks like it's just better if I return a struct if these 
goroutines are operating independently anyway.

On Monday, March 13, 2017 at 12:20:42 AM UTC-7, Konstantin Khomoutov wrote:
>
> On Sun, 12 Mar 2017 23:39:59 -0700 (PDT) 
> Albert Tedja <nicho...@gmail.com > wrote: 
>
> > I know map itself isn't threadsafe, but I am just wondering how 
> > threadsafe it is if you can be absolutely sure that each goroutine 
> > accesses a different key in the map. 
> > Say, goroutine 1 accesses mymap["1"] 
> > and goroutine 2 accesses mymap["2"] and so on. 
>
> Contrary to a struct type, values of which are just pretty "static" 
> pieces of memory, where the compiler known an offset (in bytes) of each 
> field relative to the value's starting address, a value of a map type 
> contains a pointer to an intricate *dynamic* thing, where each insertion 
> of a new value might lead to drastic changes like moving of unrelated 
> values already stored in that map in memory. 
>
> Because of this, the only thing guaranteed to work concurrently with Go 
> maps is reading them.  So if your goroutites only read a map value, 
> then it does not matter which values they read.  If they write to a map 
> (that is, insert into it or delete from it), you must synchronize the 
> accesses to that no write even happens concurrently with either another 
> write or a read. 
>
> On the other hand, consider that if you store in the map pointers to 
> actual values which are themselves not stored in a map, then, after 
> reading such a pointer from a map, you're free to deal with the value 
> it points to concurrently with map modification.  That's because in 
> this scenario, the only values stored by the map are pointers, and 
> hence insertion to the map and deletions from it might move those 
> pointers in memory but not the values they point to. 
>

-- 
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.

[go-nuts] thread safety of map when each goroutine access a different key

[Albert Tedja]

Hello,

I know map itself isn't threadsafe, but I am just wondering how threadsafe 
it is if you can be absolutely sure that each goroutine accesses a 
different key in the map.
Say, goroutine 1 accesses mymap["1"]
and goroutine 2 accesses mymap["2"] and so on.

Thank you in advance.

-- 
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.