[go-nuts] Re: Using Go in a locked down SOC2 environment (dependency management hell)
On Friday, January 6, 2017 at 3:04:05 PM UTC-5, Jacek Furmankiewicz wrote: > > Hi Daniel. > > I participated in the great Go survey on dependency management a while > back and raised these concerns there. > I read the summary of that once it was completed and was kinda > disappointed to see that none of this points seem to be getting addressed > or even acknowledged as a problem. > > > https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/?utm_source=golangweekly&utm_medium=email > When writing that piece, I sought to strike a balance between providing a high-level summary that would be approachable for people who've not been closely following this topic, and providing the sort of detail that those who HAVE been following it want. Unfortunately, that means that some cases, like this one, didn't get mentioned, and don't appear in the docs released by the committee so far. But this issue has been raised in the past, and it is on our radar. In a glide context (and, sorry, I've not responded to that issue you've opened yet), both of these issues touch on some parts of it: https://github.com/Masterminds/glide/issues/372 https://github.com/Masterminds/glide/issues/594 > > Sure, govendor can force using a private repo for a library. Not it does > not force it for all its dependencies, so you're back to the same clunky > management of every single library with a custom path/repo for every single > one of them. > Right, this is one of the key problems. There's another glide issue where someone raised this point, but I can't seem to lay hands on it right now. The crucial feature here is not individual overrides, but a more general ruleset. The challenges that continue to bounce around in my mind all have to do with having clear portability guarantees. > > The core issue is Go's insistence on using the VCS path of a library as > its import path, unlike any other language out there. > There is no way to create a central repo with all packages and point to > it. Even Rust got this right on day one, with crates.io. > The core issue is really about deciding what names - that is, import paths - mean to the dep mgmt tooling. I don't want to try to crack open the whole problem on this thread here, as it touches too many different problems for productive drive-by discussion. But to my mind, when we tackle this problem (and it is part of the plan), solutions for a bunch of things will fall out pretty directly therefrom: 1. Transparent mirroring/proxying of interactions with sources 2. Package/version whitelists and/or blacklists (something you mentioned earlier) 3. Simultaneous development on multiple local projects that import each other 4. A central package registry, should we decide that's a good idea 5. If #4, then certainly, the ability to run your own package registry So, while this isn't our immediate priority, it's certainly not forgotten, either. > > I understand this was one of the opinionated decisions the Go creators > made in the early days, > but the end result is that we simply cannot even touch Go as a potential > language. > > I don't think this is a side effect they envisioned when they made this > decision. :-( > -- 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] Multiple goroutine timeout for waitgroup not working
Thanks very much John
Let me check
Rgds,
Abhi
On Sunday, January 8, 2017 at 8:18:03 PM UTC+5:30, John Souvestre wrote:
>
> Hi Abhi.
>
>
>
> An afterthought: For the “done” case, add a check to clear out any “cs”
> values which might come in just before the “done” signal. You won’t need
> to worry about this in the “timeout” case.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* John Souvestre [mailto:jo...@souvestre.com ]
> *Sent:* 2017 January 08, Sun 07:27
> *To:* 'golang-nuts'
> *Subject:* RE: [go-nuts] Multiple goroutine timeout for waitgroup not
> working
>
>
>
> Hi Abhi.
>
>
>
> I’m thinking something like this might do the job. Call monitorWorker(wg,
> done) as a goroutine and change it to do just the wg.Wait then send a
> signal on the “done” channel.
>
>
>
> Next, start a goroutine which signals on a “timeout” channel if the
> timeout is exceeded.
>
>
>
> Finally, change GetWorkerValues to be an endless loop containing a select
> with three cases: “<-cs” (add new value to array), “<-done” (break), and
> “<-timeout” (break). After the loop, send the array.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* desaia...@gmail.com [mailto:de...@gmail.com
> ]
> *Sent:* 2017 January 08, Sun 07:10
> *To:* John Souvestre
> *Cc:* golang-nuts
> *Subject:* Re: [go-nuts] Multiple goroutine timeout for waitgroup not
> working
>
>
>
> Hi John
>
>
>
> Can you please help me to apply correct logic to achieve it
>
>
>
> Haven't found any solution on the net. All articles are talking about only
> 1 routine timeout and not multiple
>
>
>
> Thank you very much
>
>
>
> Rgds
>
>
>
> Abhi
>
>
> On Jan 8, 2017, at 6:36 PM, John Souvestre > wrote:
>
> Hi Abhi.
>
>
>
> I believe that your logic is faulty. The timeout does take place – but it
> doesn’t really do what you wanted, I think.
>
>
>
> GetWorkerValues isn’t going to send it’s info because the “range cs” can’t
> finish until the channel is closed. The channel is not closed until both
> workers are finished – timeout or not, thus it always contains the info for
> both workers.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [
> mailto:go...@googlegroups.com ] *On Behalf Of *
> desaia...@gmail.com
> *Sent:* 2017 January 08, Sun 06:24
> *To:* golang-nuts
> *Subject:* Re: [go-nuts] Multiple goroutine timeout for waitgroup not
> working
>
>
>
> hi John
>
>
>
> I am expecting work2 should not include in
>
>
>
> headers = <-messgesResponse
>
>
>
> so output of below should be Len = 1 and should print only work 1 only and
> not 2 ( as work 2 is timed out )
>
>
>
> fmt.Printf("len > %s\n", len(headers))
>
>
>
> for i:=0;i
> fmt.Printf("Name > %s\n", headers[i].Name)
>
> }
>
>
>
> basically workgroup timeout doesnt close the timeout works
>
>
>
> select {
>
> case <-time.After(2 * time.Second): //This works
> but dont stop the work2
>
> return
>
> }
>
>
>
> Do I need to explicitly close them in
>
>
>
> select {
>
> case <-time.After(2 * time.Second):
>
> close(cs)
>
> return
>
> }
>
>
>
> Thanks for the help
>
>
>
> Rgds,
>
>
>
> Abhi
>
> On Sunday, January 8, 2017 at 5:40:01 PM UTC+5:30, John Souvestre wrote:
>
> Hi Abhi.
>
>
>
> I believe that the wait group timeout (in monitorWorker) was set to 2
> seconds in the code you posted.
>
>
>
> I put a debugging print in the timeout case, and it is taking place.
>
>
>
> What were you expecting to see?
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [mailto:golan...@googlegroups.com] *On
> Behalf Of *desaia...@gmail.com
> *Sent:* 2017 January 08, Sun 05:48
> *To:* golang-nuts
> *Subject:* Re: [go-nuts] Multiple goroutine timeout for waitgroup not
> working
>
>
>
> hi John
>
>
>
> Thanks for the reply
>
>
>
> sorry
>
>
>
> I mean Work2 takes => 3 seconds
>
> work1 takes => 1 seconds
>
>
>
> Wait group timeout is => 1 seconds
>
>
>
> It is expected that only Work1 should get done and Work 2 should get
> timeout which is not happening
>
>
>
> Waitgroup waits for both work.. program doing something wrong
>
>
>
> func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
> string) {
>
>
>
> defer wg.Done()
>
>
>
> v1 := new(TestStruct)
>
> v1.Name = tokenNumber
>
> time.Sleep(3 * time.Second)
>
>
>
> message <- v1
>
>
>
> fmt.Printf("finished %s\n", tokenNumber)
>
> }
>
>
>
> Thanks,
>
>
>
> Abhi
>
>
> On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
>
> What do you see when you run it? I se
[go-nuts] [ANN]: golinks - smart sharable bookmarks, shortcuts and commands for your web browser
Hi All, Ever used anything like Bunny1 or Yubnub? golinks is a tool ( a web app really) that you can point your web browser's default search engine at and providers you with powerful ways to create sharable bookmarks, aliases, shortcuts and custom commands. Once you have your web browser configured to point at your instance; e.g: http://localhost:8000/?q=%s Then typing (for example) in your web browser: g foo bar Takes you straight to a google search for "foo bar" Project Page: https://github.com/prologic/golinks This is alpha quality software at this time; but it works and is being used as my default search engine in a small network. Feedback, ideas, issues and pull-requests welcome! cheers James -- 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] database/sql: special interest group
In go1.8 I worked on adding a number of features to "database/sql". I hope to address a few more needs in the go1.9 cycle. To that end I want to gather some other voices who both use Go and who use SQL based database servers regularly. Even if you don't use "database/sql" I would still like to hear from you. I've created a new group https://groups.google.com/forum/#!forum/golang-sql for such discussion and interest. I would like to discuss a few of the issues listed at https://github.com/golang/go/issues/assigned/kardianos with a wider audience instead of the one or two people who happened upon the issue at hand. In the further future I would like to discuss connection pool and driver optimizations, testing, and a dedicated (non-std lib) package for defining SQL types, common utilities such as table buffers, and interfaces like bulk load. I think it would also be good to vet drivers through a common testing suit and setup CI for drivers without it yet. Thanks, -Daniel -- 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: Explosion in memory usage when compiling a big file
This option ? https://github.com/jteeuwen/go-bindata#lower-memory-footprint
Le dimanche 8 janvier 2017 21:46:15 UTC+1, Dave Cheney a écrit :
>
> This is a somewhat known issue. Each token in a parsered .go file is
> represented by a Node structure inside the program. The Node structure is
> large, especially on 64 bit systems.
>
> Normally this is not a problem, but in th e case where code has large
> tables of data memory usage when compiling can be unexpectedly high.
>
> This problem is being worked on, but not solution exists in a shipping
> version of Go yet.
>
> The mitigation to this problem is to reduce the number of parsed tokens,
> so, rather than
>
> var data = []byte{ 65, 66, 67, 68, 69, 70}
>
> Do
>
> const data = "abcdef"
>
> The latter produces O(1) tokens per declaration vs O(N) tokens for the
> former.
>
> If the data cannot be represented as text, compressing and base64 encoding
> can help.
>
> I'm not sure what strategy go-bindata uses, but you can check this
> yourself looking at its generated output.
>
> Dave
>
>
--
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] Re: Is there a 1 mb project to test compilation speed?
I'm sorry, I don't understand the question. Can you please restate 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Is there a 1 mb project to test compilation speed?
Hi Dave. Am I correct in assuming that the build time is for a complete “build”, not an incremental “install”? If so, about how long does an updated install take for just minor changes? Thanks, John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Dave Cheney Sent: 2017 January 08, Sun 13:36 To: golang-nuts Subject: [go-nuts] Re: Is there a 1 mb project to test compilation speed? I published a series of blog posts comparing compile times over various releases of Go. The source of the benchmarks, the packages I compiled and timed, are online and linked from https://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements. The jujud tests compile some 512 packages of various line counts. On Monday, 9 January 2017 05:17:56 UTC+11, me wrote: Hi, I'd like to see how long it takes to compile average code, about 1 mb, or anything that makes the usual overhead insignificant. Just to see how cool it would be to convert a C++ project to Golang. -- 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.
[go-nuts] Re: A question about the atomic operations in golang
Shouldn't this particular case be ok? From the memory
doc: https://golang.org/ref/mem
The go statement that starts a new goroutine happens before the goroutine's
> execution begins.
So the write has to happen before the goroutine starts. At least that's
what the example indicates:
> For example, in this program:
var a string
func f() {
print(a)
}
func hello() {
a = "hello, world"
go f()
}
> calling hello will print "hello, world" at some point in the future
> (perhaps after hello has returned).
On Sunday, January 8, 2017 at 1:17:56 PM UTC-5, 陈诚 wrote:
> Is the size of a pointer value 32 bits or 64 bits in golang when build
> with `GOARCH=amd64` option specified and running on 64-bit OS?
> If it's 64-bit size, is a global pointer value 8-byte aligned in memory so
> that a read or write operation of that pointer value is carried out
> atomically?
> For example, in the following code, is it possible that the global pointer
> p is only partially updated when the read goroutine read the pointer?
> var p *int
>
> void main() {
> i := 1
> p = &i
> go func() { fmt.Println(*p) } ()
> }
>
> The scenario I'm concerning is that there is only one write but multiple
> reads on a global pointer value, and reading of an old value of the pointer
> is not important. Thanks 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.
[go-nuts] Explosion in memory usage when compiling a big file
This is a somewhat known issue. Each token in a parsered .go file is
represented by a Node structure inside the program. The Node structure is
large, especially on 64 bit systems.
Normally this is not a problem, but in th e case where code has large tables of
data memory usage when compiling can be unexpectedly high.
This problem is being worked on, but not solution exists in a shipping version
of Go yet.
The mitigation to this problem is to reduce the number of parsed tokens, so,
rather than
var data = []byte{ 65, 66, 67, 68, 69, 70}
Do
const data = "abcdef"
The latter produces O(1) tokens per declaration vs O(N) tokens for the former.
If the data cannot be represented as text, compressing and base64 encoding can
help.
I'm not sure what strategy go-bindata uses, but you can check this yourself
looking at its generated output.
Dave
--
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 there a 1 mb project to test compilation speed?
I published a series of blog posts comparing compile times over various releases of Go. The source of the benchmarks, the packages I compiled and timed, are online and linked from https://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements. The jujud tests compile some 512 packages of various line counts. On Monday, 9 January 2017 05:17:56 UTC+11, me wrote: > > Hi, I'd like to see how long it takes to compile average code, about 1 mb, > or anything that makes the usual overhead insignificant. Just to see how > cool it would be to convert a C++ project to Golang. > -- 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 question about the atomic operations in golang
What you are talking about is called a torn write, which can occur if a value is written to memory but not aligned properly as the processor or memory subsystem must convert this write into two to correct for the miss alignment. Most processors that I know of, and all the ones that Go supports, assuming that the value is correctly alligned will write the value atomically, IE another processor will not see a partially written value. However, I must caution you that while you say it is ok for one processor to see an old value for a time, this is not how the Go memory model works. There are no concessions for "for a time" and so on, the updated value may never be written to memory, or the old value may continue to be visible for the remainder of the program's run time. The memory model describes what you ask for as a data race and states that your program is no longer guaranteed to run correctly. Or put more suscinctly, if you have a data race, the result of your program is undefined. -- 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] does the syscall package allow zero bytes in the filename?
Alright, thanks! On Sat, Jan 7, 2017 at 11:43 AM Ian Lance Taylor wrote: > On Sat, Jan 7, 2017 at 7:00 AM, anmol via golang-nuts > wrote: > > Was the suggestion from this commit > > > https://github.com/golang/go/commit/706832a0882c7300889238d5f4d476dc2ee83ad0 > > ever implemented? > > Yes: https://golang.org/cl/6458050 . > > Ian > -- 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] Is there a 1 mb project to test compilation speed?
Hi, I'd like to see how long it takes to compile average code, about 1 mb, or anything that makes the usual overhead insignificant. Just to see how cool it would be to convert a C++ project to Golang. -- 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] Multiple goroutine timeout for waitgroup not working
The ran the code on play, seems to come out within 2 seconds.
https://play.golang.org/p/yZIAvXI8IX
On Sun, Jan 8, 2017 at 12:53 PM, wrote:
>
> Can you please help to correct below program where timeout not seems
> working
>
> Work 1 - have 1 second
> Work 2 - have 3 second
> Total Timeout - 2 sec
>
> program wait for entire 3 seconds and return both values rather than value
> from Work 1
>
> Program >
>
> package main
>
> import (
> "fmt"
> "time"
> "sync"
> )
>
>
> type TestStruct struct {
> Name string
> }
>
> func main() {
>
> wg := &sync.WaitGroup{}
> messges := make(chan *TestStruct, 1)
>
> wg.Add(1)
> go Work1(messges, wg, "1")
> wg.Add(1)
> go Work2(messges, wg, "2")
>
> monitorWorker(wg, messges)
>
> messgesResponse := make(chan []*TestStruct)
> go GetWorkerValues(messges, messgesResponse)
>
> headers := make([]*TestStruct, 0)
> headers = <-messgesResponse
>
> fmt.Printf("len > %s\n", len(headers))
>
> for i:=0;i fmt.Printf("Name > %s\n", headers[i].Name)
> }
> }
>
>
>
> func monitorWorker(wg *sync.WaitGroup, cs chan *TestStruct) {
> go func() {
> defer close(cs)
> wg.Wait()
> }()
>
> select {
> case <-time.After(2 * time.Second):
> return
> }
> }
> func Work1(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
> string) {
> defer wg.Done()
>
> v1 := new(TestStruct)
> v1.Name = tokenNumber
> time.Sleep(1 * time.Second)
>
> message <- v1
> fmt.Printf("finished %s\n", tokenNumber)
> }
>
> func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
> string) {
> defer wg.Done()
>
> v1 := new(TestStruct)
> v1.Name = tokenNumber
> time.Sleep(1 * time.Second)
>
> message <- v1
>
> fmt.Printf("finished %s\n", tokenNumber)
> }
>
>
> func GetWorkerValues(cs <-chan *TestStruct, response chan<- []*TestStruct)
> {
> var val []*TestStruct
> for header := range cs {
> val = append(val, header)
> }
> response <- val
> }
>
>
> Thanks,
>
> Abhi
>
> --
> 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.
[go-nuts] A question about the atomic operations in golang
Is the size of a pointer value 32 bits or 64 bits in golang when build with
`GOARCH=amd64` option specified and running on 64-bit OS?
If it's 64-bit size, is a global pointer value 8-byte aligned in memory so
that a read or write operation of that pointer value is carried out
atomically?
For example, in the following code, is it possible that the global pointer
p is only partially updated when the read goroutine read the pointer?
var p *int
void main() {
i := 1
p = &i
go func() { fmt.Println(*p) } ()
}
The scenario I'm concerning is that there is only one write but multiple
reads on a global pointer value, and reading of an old value of the pointer
is not important. Thanks 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.
Re: [go-nuts] Re: Efficient ForEach() on a map protected by a mutex
You can compile/run with -race :
https://golang.org/doc/articles/race_detector.html
On Saturday, January 7, 2017 at 11:59:40 PM UTC-8, tsuna wrote:
>
> On Sat, Jan 7, 2017 at 7:00 PM, 'Keith Randall' via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>>
>>
>> On Friday, January 6, 2017 at 5:12:54 PM UTC-8, tsuna wrote:
>>>
>>> Hi there,
>>> I have a struct that contains an unexported map protected by a mutex,
>>> let’s say something like:
>>>
>>> type Map struct {
>>> mtx sync.Mutex
>>> col map[string]interface{}
>>> }
>>>
>>> I want to implement a ForEach method that works in O(1) space and
>>> doesn’t hold the mutex while working on each entry. This is what I have:
>>>
>>> func (m *Map) ForEach(fn func(k, v interface{})) {
>>> m.mtx.Lock()
>>> for k, v := range m.col {
>>> m.mtx.Unlock()
>>> fn(k, v)
>>> m.mtx.Lock()
>>> }
>>> m.mtx.Unlock()
>>> }
>>>
>>> (runnable example: https://play.golang.org/p/tX2lCCYWxq)
>>>
>>> The language spec says:
>>>
3. The iteration order over maps is not specified and is not guaranteed
to be the same from one iteration to the next. If map entries that have
not
yet been reached are removed during iteration, the corresponding iteration
values will not be produced. If map entries are created during iteration,
that entry may be produced during the iteration or may be skipped. The
choice may vary for each entry created and from one iteration to the next.
If the map is nil, the number of iterations is 0.
>>>
>>>
>>> With the caveats mentioned above regarding concurrent
>>> deletions/insertions in mind, is this implementation of ForEach correct?
>>> Is there a better way?
>>>
>>>
>> I'm not sure I understand what you're trying to guarantee.
>>
>
> That the code is race-free. The guarantees on data access are pretty
> loose – fn() could be called on a key-value pair while it’s being
> removed/changed by another goroutine. That’s okay.
>
>
>> The code you've shown looks fine, but the devil is in the details of what
>> fn does.
>>
>> The fundamental constraint is that you need to make sure that no two
>> concurrent operations, at least one of which is a write, happen to the
>> map. Treat iteration as a read. And it isn't one read extending for the
>> whole loop. It is one "instantaneous" read each time a new k,v is assigned.
>> So fn can read all it wants.
>> If fn writes, those writes must be synchronized so that they do not
>> happen concurrently with the ForEach goroutine iterating.
>> So if fn writes in the same goroutine that ForEach is running in, that is
>> fine.
>> If fn spawns other goroutines to write to the map, asks other goroutines
>> to write to the map via channels, etc. then those accesses must be properly
>> synchronized.
>> One way to do that is to use the same lock as you used in ForEach around
>> those accesses.
>>
>
> Yes, that’s exactly what’s happening. The contrived example I showed only
> included ForEach(), but I also have Get(k) and Set(k, v) methods on this
> struct, which can be called concurrently from other goroutines. Of course
> they also acquire the same mutex.
>
> Alright, so thanks for checking this wasn’t insane. The code looks weird,
> but it is what it is.
>
> --
> Benoit "tsuna" Sigoure
>
--
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] Explosion in memory usage when compiling a big file
Hi, so I was trying to embed JS and HTML assets in a Go file using go-bindata and ended up with a Go file of 4Mib, and I noticed compiling it consumes all my system's memory. I'm on Windows and using the resource monitor I can see compile.exe memory usage grow to more than 15Gib in a couple of seconds. I have 16Gib on this system so it looks like it uses everything available. I'm wondering if this is expected behaviour ? I know a 4Mib file isn't common (and shouldn't be) but maybe there's a bug somewhere ? 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.
[go-nuts] [ANN] Nuklear GUI package for Go now supports various backends including Android
Hello Gophers. Nuklear is an immediate mode graphical user interface toolkit written in ANSI C, it is platform agnostic and custom backends can be implemented to execute drawing commands and handle input on any platform. I wrote backends for desktop GLFW OpenGL 2.1 and 3.2, as well as an Android backend for EGL OpenGL ES 2 and ES 3 in Go programming language. So now it's rather easy to create sophisticated GUI apps for Android in Go. Please see examples. https://github.com/golang-ui/nuklear https://github.com/xlab/android-go https://www.youtube.com/watch?v=3-MiceegZlM Feedback is welcome! -- 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] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
An afterthought: For the “done” case, add a check to clear out any “cs” values
which might come in just before the “done” signal. You won’t need to worry
about this in the “timeout” case.
John
John Souvestre - New Orleans LA
From: John Souvestre [mailto:j...@souvestre.com]
Sent: 2017 January 08, Sun 07:27
To: 'golang-nuts'
Subject: RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
I’m thinking something like this might do the job. Call monitorWorker(wg,
done) as a goroutine and change it to do just the wg.Wait then send a signal on
the “done” channel.
Next, start a goroutine which signals on a “timeout” channel if the timeout is
exceeded.
Finally, change GetWorkerValues to be an endless loop containing a select with
three cases: “<-cs” (add new value to array), “<-done” (break), and “<-timeout”
(break). After the loop, send the array.
John
John Souvestre - New Orleans LA
From: desaiabhi...@gmail.com [mailto:desaiabhi...@gmail.com]
Sent: 2017 January 08, Sun 07:10
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi John
Can you please help me to apply correct logic to achieve it
Haven't found any solution on the net. All articles are talking about only 1
routine timeout and not multiple
Thank you very much
Rgds
Abhi
On Jan 8, 2017, at 6:36 PM, John Souvestre wrote:
Hi Abhi.
I believe that your logic is faulty. The timeout does take place – but it
doesn’t really do what you wanted, I think.
GetWorkerValues isn’t going to send it’s info because the “range cs” can’t
finish until the channel is closed. The channel is not closed until both
workers are finished – timeout or not, thus it always contains the info for
both workers.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 06:24
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
I am expecting work2 should not include in
headers = <-messgesResponse
so output of below should be Len = 1 and should print only work 1 only and not
2 ( as work 2 is timed out )
fmt.Printf("len > %s\n", len(headers))
for i:=0;i %s\n", headers[i].Name)
}
basically workgroup timeout doesnt close the timeout works
select {
case <-time.After(2 * time.Second): //This works but
dont stop the work2
return
}
Do I need to explicitly close them in
select {
case <-time.After(2 * time.Second):
close(cs)
return
}
Thanks for the help
Rgds,
Abhi
On Sunday, January 8, 2017 at 5:40:01 PM UTC+5:30, John Souvestre wrote:
Hi Abhi.
I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
in the code you posted.
I put a debugging print in the timeout case, and it is taking place.
What were you expecting to see?
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com
[mailto:golan...@googlegroups.com ] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 05:48
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get timeout
which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com [mailto:golan...@googlegroups.com] On Behalf Of
desaia...@gmail.com
Sent: 2017 Januar
Re: [go-nuts] Using Go in a locked down SOC2 environment (dependency management hell)
On Fri, Jan 6, 2017 at 8:38 PM Jacek Furmankiewicz
wrote:
>
> We've had really difficult individuals who refused to be bothered with
> going through proper license review.
> Some of them don't work here any more.
>
>
This is a social problem with the people you've hired, or with how they
have been instructed. You can't block copy/paste. You can't block blind
injection of random code from {stuck,stack} {overfail,overflow}. You can't
stop people from memorizing code at home and then adding said code to your
project. In order to handle licensing issues around code, your people must
be on-board and understand the problem.
Usually, the reason you end up in a bad situation is due to complex
factors, so you can't place the blame or the fault on any single
individual, or on the management. Rather, you have to understand that more
than a single factor often leads to sick work environments where these
things happen. Sometimes, the guy who inserts illegal code into the code
base does it because he is under pressure to deliver. Which means that the
fault is partially him, but also partially management. In that case, firing
the guy will not put out the tire fire you have. Another poor individual
will just takes the same seat and ends in the same situation months down
the line.
If you can't survive a rejection of an audit, you must have procedures
internally to remove the risk of rejection. These are usually a combination
of technical solutions (code search) and human solutions (manual review).
There is no way you can move the risk to 0%, but you can get it close.
Also, consider social solutions (company culture).
My suggestion is to run an internal vendoring tree from which you are
allowed to pull software packages. And then make it a process to add
something to the tree. This will slow down development, short term, but I
have a hunch you will gain from such a procedure long-term. In addition to
solving the audit problem it also solves a number of other problems:
* You can reproduce builds
* You make updating a package a deliberate decision
* You guard against people who are not able to manage a stable API for
backwards compatibility
* You can run internal patches on software if the maintainer of the
software on the outside are not willing to handle the problem you have.
The price you pay are:
* You have to watch for security updates more
* If you diverge too much from the external project, you can't merge their
strain of changes into your world easily
* You must spend time to keep things up-to-date
In your case, I think the benefits outweigh the cost, simply because an
audit is always lurking in the back.
--
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] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
I’m thinking something like this might do the job. Call monitorWorker(wg,
done) as a goroutine and change it to do just the wg.Wait then send a signal on
the “done” channel.
Next, start a goroutine which signals on a “timeout” channel if the timeout is
exceeded.
Finally, change GetWorkerValues to be an endless loop containing a select with
three cases: “<-cs” (add new value to array), “<-done” (break), and “<-timeout”
(break). After the loop, send the array.
John
John Souvestre - New Orleans LA
From: desaiabhi...@gmail.com [mailto:desaiabhi...@gmail.com]
Sent: 2017 January 08, Sun 07:10
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi John
Can you please help me to apply correct logic to achieve it
Haven't found any solution on the net. All articles are talking about only 1
routine timeout and not multiple
Thank you very much
Rgds
Abhi
On Jan 8, 2017, at 6:36 PM, John Souvestre wrote:
Hi Abhi.
I believe that your logic is faulty. The timeout does take place – but it
doesn’t really do what you wanted, I think.
GetWorkerValues isn’t going to send it’s info because the “range cs” can’t
finish until the channel is closed. The channel is not closed until both
workers are finished – timeout or not, thus it always contains the info for
both workers.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 06:24
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
I am expecting work2 should not include in
headers = <-messgesResponse
so output of below should be Len = 1 and should print only work 1 only and not
2 ( as work 2 is timed out )
fmt.Printf("len > %s\n", len(headers))
for i:=0;i %s\n", headers[i].Name)
}
basically workgroup timeout doesnt close the timeout works
select {
case <-time.After(2 * time.Second): //This works but
dont stop the work2
return
}
Do I need to explicitly close them in
select {
case <-time.After(2 * time.Second):
close(cs)
return
}
Thanks for the help
Rgds,
Abhi
On Sunday, January 8, 2017 at 5:40:01 PM UTC+5:30, John Souvestre wrote:
Hi Abhi.
I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
in the code you posted.
I put a debugging print in the timeout case, and it is taking place.
What were you expecting to see?
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com
[mailto:golan...@googlegroups.com ] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 05:48
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get timeout
which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com [mailto:golan...@googlegroups.com] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 01:23
To: golang-nuts
Subject: [go-nuts] Multiple goroutine timeout for waitgroup not working
Can you please help to correct below program where timeout not seems working
Work 1 - have 1 second
Work 2 - have 3 second
Total Timeout - 2 sec
program wait for entire 3 seconds and return both values rather than value from
Work 1
Program >
package main
import (
"fmt"
"time"
Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi John
Can you please help me to apply correct logic to achieve it
Haven't found any solution on the net. All articles are talking about only 1
routine timeout and not multiple
Thank you very much
Rgds
Abhi
> On Jan 8, 2017, at 6:36 PM, John Souvestre wrote:
>
> Hi Abhi.
>
> I believe that your logic is faulty. The timeout does take place – but it
> doesn’t really do what you wanted, I think.
>
> GetWorkerValues isn’t going to send it’s info because the “range cs” can’t
> finish until the channel is closed. The channel is not closed until both
> workers are finished – timeout or not, thus it always contains the info for
> both workers.
>
> John
>
> John Souvestre - New Orleans LA
>
> From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
> Behalf Of desaiabhi...@gmail.com
> Sent: 2017 January 08, Sun 06:24
> To: golang-nuts
> Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
>
> hi John
>
> I am expecting work2 should not include in
>
> headers = <-messgesResponse
>
> so output of below should be Len = 1 and should print only work 1 only and
> not 2 ( as work 2 is timed out )
>
> fmt.Printf("len > %s\n", len(headers))
>
> for i:=0;i fmt.Printf("Name > %s\n", headers[i].Name)
> }
>
> basically workgroup timeout doesnt close the timeout works
>
> select {
> case <-time.After(2 * time.Second): //This works but
> dont stop the work2
> return
> }
>
> Do I need to explicitly close them in
>
> select {
> case <-time.After(2 * time.Second):
> close(cs)
> return
> }
>
> Thanks for the help
>
> Rgds,
>
> Abhi
>
> On Sunday, January 8, 2017 at 5:40:01 PM UTC+5:30, John Souvestre wrote:
> Hi Abhi.
>
> I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
> in the code you posted.
>
> I put a debugging print in the timeout case, and it is taking place.
>
> What were you expecting to see?
>
> John
>
> John Souvestre - New Orleans LA
>
> From: golan...@googlegroups.com [mailto:golan...@googlegroups.com] On Behalf
> Of desaia...@gmail.com
> Sent: 2017 January 08, Sun 05:48
> To: golang-nuts
> Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
>
> hi John
>
> Thanks for the reply
>
> sorry
>
> I mean Work2 takes => 3 seconds
> work1 takes => 1 seconds
>
> Wait group timeout is => 1 seconds
>
> It is expected that only Work1 should get done and Work 2 should get timeout
> which is not happening
>
> Waitgroup waits for both work.. program doing something wrong
>
> func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string)
> {
>
> defer wg.Done()
>
> v1 := new(TestStruct)
> v1.Name = tokenNumber
> time.Sleep(3 * time.Second)
>
> message <- v1
>
> fmt.Printf("finished %s\n", tokenNumber)
> }
>
> Thanks,
>
> Abhi
>
> On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
> What do you see when you run it? I see:
>
>finished 1
>finished 2
> len > %!s(int=2) ç Using a string format for an int
>Name > 1
>Name > 2
>
> Ø Work 2 - have 3 second
>
>
> I’m not sure exactly what you are trying to do, but I suspect that changing
> “messges” to hold 2 items might make it work.
>
> messges := make(chan *TestStruct, 2)
>
> I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
> then Work2 will block since the channel is full (or until you close it).
>
> John
>
> John Souvestre - New Orleans LA
>
> From: golan...@googlegroups.com [mailto:golan...@googlegroups.com] On Behalf
> Of desaia...@gmail.com
> Sent: 2017 January 08, Sun 01:23
> To: golang-nuts
> Subject: [go-nuts] Multiple goroutine timeout for waitgroup not working
>
>
> Can you please help to correct below program where timeout not seems working
>
> Work 1 - have 1 second
> Work 2 - have 3 second
> Total Timeout - 2 sec
>
> program wait for entire 3 seconds and return both values rather than value
> from Work 1
>
> Program >
>
> package main
>
> import (
> "fmt"
> "time"
> "sync"
> )
>
>
> type TestStruct struct {
> Name string
> }
>
> func main() {
>
> wg := &sync.WaitGroup{}
> messges := make(chan *TestStruct, 1)
>
> wg.Add(1)
> go Work1(messges, wg, "1")
> wg.Add(1)
> go Work2(messges, wg, "2")
>
> monitorWorker(wg, messges)
>
> messgesResponse := make(chan []*TestStruct)
> go GetWorkerValues(messges, messgesResponse)
>
> headers := m
RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
I believe that your logic is faulty. The timeout does take place – but it
doesn’t really do what you wanted, I think.
GetWorkerValues isn’t going to send it’s info because the “range cs” can’t
finish until the channel is closed. The channel is not closed until both
workers are finished – timeout or not, thus it always contains the info for
both workers.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 06:24
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
I am expecting work2 should not include in
headers = <-messgesResponse
so output of below should be Len = 1 and should print only work 1 only and not
2 ( as work 2 is timed out )
fmt.Printf("len > %s\n", len(headers))
for i:=0;i %s\n", headers[i].Name)
}
basically workgroup timeout doesnt close the timeout works
select {
case <-time.After(2 * time.Second): //This works but
dont stop the work2
return
}
Do I need to explicitly close them in
select {
case <-time.After(2 * time.Second):
close(cs)
return
}
Thanks for the help
Rgds,
Abhi
On Sunday, January 8, 2017 at 5:40:01 PM UTC+5:30, John Souvestre wrote:
Hi Abhi.
I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
in the code you posted.
I put a debugging print in the timeout case, and it is taking place.
What were you expecting to see?
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com
[mailto:golan...@googlegroups.com ] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 05:48
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get timeout
which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com [mailto:golan...@googlegroups.com] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 01:23
To: golang-nuts
Subject: [go-nuts] Multiple goroutine timeout for waitgroup not working
Can you please help to correct below program where timeout not seems working
Work 1 - have 1 second
Work 2 - have 3 second
Total Timeout - 2 sec
program wait for entire 3 seconds and return both values rather than value from
Work 1
Program >
package main
import (
"fmt"
"time"
"sync"
)
type TestStruct struct {
Name string
}
func main() {
wg := &sync.WaitGroup{}
messges := make(chan *TestStruct, 1)
wg.Add(1)
go Work1(messges, wg, "1")
wg.Add(1)
go Work2(messges, wg, "2")
monitorWorker(wg, messges)
messgesResponse := make(chan []*TestStruct)
go GetWorkerValues(messges, messgesResponse)
headers := make([]*TestStruct, 0)
headers = <-messgesResponse
fmt.Printf("len > %s\n", len(headers))
for i:=0;i %s\n", headers[i].Name)
}
}
func monitorWorker(wg *sync.WaitGroup, cs chan *TestStruct) {
go func() {
defer close(cs)
wg.Wait()
}()
select {
case <-time.After(2 * time.Second):
return
}
Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi John
I have taken code from one of the site to make it work for me
In real program, spawning 100 goroutine to do the work with timeout 2 sec but
found that entire program takes time which is equal to time taken by routine
which finishes last irrespective of workgroup timeout
So need help to fix program so that timeout will force to close and merge the
work done by all routines within 2 sec where few routines will return work
where as few will not because of timeout
Thanks
Abhi
> On Jan 8, 2017, at 5:42 PM, John Souvestre wrote:
>
> Hi again.
>
> Did you perhaps intend to make the call to monitorWorker() as a goroutine?
> That would let it run in parallel with the rest of main.
>
> John
>
> John Souvestre - New Orleans LA
>
> From: John Souvestre [mailto:j...@souvestre.com]
> Sent: 2017 January 08, Sun 06:10
> To: 'golang-nuts'
> Subject: RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
>
> Hi Abhi.
>
> I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
> in the code you posted.
>
> I put a debugging print in the timeout case, and it is taking place.
>
> What were you expecting to see?
>
> John
>
> John Souvestre - New Orleans LA
>
> From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
> Behalf Of desaiabhi...@gmail.com
> Sent: 2017 January 08, Sun 05:48
> To: golang-nuts
> Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
>
> hi John
>
> Thanks for the reply
>
> sorry
>
> I mean Work2 takes => 3 seconds
> work1 takes => 1 seconds
>
> Wait group timeout is => 1 seconds
>
> It is expected that only Work1 should get done and Work 2 should get timeout
> which is not happening
>
> Waitgroup waits for both work.. program doing something wrong
>
> func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string)
> {
>
> defer wg.Done()
>
> v1 := new(TestStruct)
> v1.Name = tokenNumber
> time.Sleep(3 * time.Second)
>
> message <- v1
>
> fmt.Printf("finished %s\n", tokenNumber)
> }
>
> Thanks,
>
> Abhi
>
> On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
> What do you see when you run it? I see:
>
>finished 1
>finished 2
> len > %!s(int=2) ç Using a string format for an int
>Name > 1
>Name > 2
>
> Ø Work 2 - have 3 second
>
>
> I’m not sure exactly what you are trying to do, but I suspect that changing
> “messges” to hold 2 items might make it work.
>
> messges := make(chan *TestStruct, 2)
>
> I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
> then Work2 will block since the channel is full (or until you close it).
>
> John
>
> John Souvestre - New Orleans LA
> --
> You received this message because you are subscribed to a topic in the Google
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/o0DYWZIlmvs/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
I am expecting work2 should not include in
headers = <-messgesResponse
so output of below should be Len = 1 and should print only work 1 only and
not 2 ( as work 2 is timed out )
fmt.Printf("len > %s\n", len(headers))
for i:=0;i %s\n", headers[i].Name)
}
basically workgroup timeout doesnt close the timeout works
select {
case <-time.After(2 * time.Second): //This works
but dont stop the work2
return
}
Do I need to explicitly close them in
select {
case <-time.After(2 * time.Second):
close(cs)
return
}
Thanks for the help
Rgds,
Abhi
On Sunday, January 8, 2017 at 5:40:01 PM UTC+5:30, John Souvestre wrote:
>
> Hi Abhi.
>
>
>
> I believe that the wait group timeout (in monitorWorker) was set to 2
> seconds in the code you posted.
>
>
>
> I put a debugging print in the timeout case, and it is taking place.
>
>
>
> What were you expecting to see?
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [mailto:
> golan...@googlegroups.com ] *On Behalf Of *
> desaia...@gmail.com
> *Sent:* 2017 January 08, Sun 05:48
> *To:* golang-nuts
> *Subject:* Re: [go-nuts] Multiple goroutine timeout for waitgroup not
> working
>
>
>
> hi John
>
>
>
> Thanks for the reply
>
>
>
> sorry
>
>
>
> I mean Work2 takes => 3 seconds
>
> work1 takes => 1 seconds
>
>
>
> Wait group timeout is => 1 seconds
>
>
>
> It is expected that only Work1 should get done and Work 2 should get
> timeout which is not happening
>
>
>
> Waitgroup waits for both work.. program doing something wrong
>
>
>
> func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
> string) {
>
>
>
> defer wg.Done()
>
>
>
> v1 := new(TestStruct)
>
> v1.Name = tokenNumber
>
> time.Sleep(3 * time.Second)
>
>
>
> message <- v1
>
>
>
> fmt.Printf("finished %s\n", tokenNumber)
>
> }
>
>
>
> Thanks,
>
>
>
> Abhi
>
>
> On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
>
> What do you see when you run it? I see:
>
>
>
>finished 1
>
>finished 2
>
> len > %!s(int=2) ç Using a string format for an int
>
>Name > 1
>
>Name > 2
>
>
>
> Ø Work 2 - have 3 second
>
>
>
> I’m not sure exactly what you are trying to do, but I suspect that
> changing “messges” to hold 2 items might make it work.
>
>
>
> messges := make(chan *TestStruct, 2)
>
>
>
> I’m guessing, but I suspect that you didn’t realize that if Work1 runs
> first, then Work2 will block since the channel is full (or until you close
> it).
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [mailto:golan...@googlegroups.com] *On
> Behalf Of *desaia...@gmail.com
> *Sent:* 2017 January 08, Sun 01:23
> *To:* golang-nuts
> *Subject:* [go-nuts] Multiple goroutine timeout for waitgroup not working
>
>
>
>
>
> Can you please help to correct below program where timeout not seems
> working
>
>
>
> Work 1 - have 1 second
>
> Work 2 - have 3 second
>
> Total Timeout - 2 sec
>
>
>
> program wait for entire 3 seconds and return both values rather than value
> from Work 1
>
>
>
> Program >
>
>
>
> package main
>
>
>
> import (
>
> "fmt"
>
> "time"
>
> "sync"
>
> )
>
>
>
>
>
> type TestStruct struct {
>
> Name string
>
> }
>
>
>
> func main() {
>
>
>
> wg := &sync.WaitGroup{}
>
> messges := make(chan *TestStruct, 1)
>
>
>
> wg.Add(1)
>
> go Work1(messges, wg, "1")
>
> wg.Add(1)
>
> go Work2(messges, wg, "2")
>
>
>
> monitorWorker(wg, messges)
>
>
>
> messgesResponse := make(chan []*TestStruct)
>
> go GetWorkerValues(messges, messgesResponse)
>
>
>
> headers := make([]*TestStruct, 0)
>
> headers = <-messgesResponse
>
>
>
> fmt.Printf("len > %s\n", len(headers))
>
>
>
> for i:=0;i
> fmt.Printf("Name > %s\n", headers[i].Name)
>
> }
>
> }
>
>
>
>
>
>
>
> func monitorWorker(wg *sync.WaitGroup, cs chan *TestStruct) {
>
> go func() {
>
> defer close(cs)
>
> wg.Wait()
>
> }()
>
>
>
> select {
>
> case <-time.After(2 * time.Second):
>
> return
>
> }
>
>
>
> }
>
> func Work1(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
> string) {
>
>
>
> defer wg.Done()
>
>
>
> v1 := new(TestStruct)
>
>
RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi again.
Did you perhaps intend to make the call to monitorWorker() as a goroutine?
That would let it run in parallel with the rest of main.
John
John Souvestre - New Orleans LA
From: John Souvestre [mailto:j...@souvestre.com]
Sent: 2017 January 08, Sun 06:10
To: 'golang-nuts'
Subject: RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
in the code you posted.
I put a debugging print in the timeout case, and it is taking place.
What were you expecting to see?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 05:48
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get timeout
which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
--
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] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
in the code you posted.
I put a debugging print in the timeout case, and it is taking place.
What were you expecting to see?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 05:48
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get timeout
which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com
[mailto:golan...@googlegroups.com ] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 01:23
To: golang-nuts
Subject: [go-nuts] Multiple goroutine timeout for waitgroup not working
Can you please help to correct below program where timeout not seems working
Work 1 - have 1 second
Work 2 - have 3 second
Total Timeout - 2 sec
program wait for entire 3 seconds and return both values rather than value from
Work 1
Program >
package main
import (
"fmt"
"time"
"sync"
)
type TestStruct struct {
Name string
}
func main() {
wg := &sync.WaitGroup{}
messges := make(chan *TestStruct, 1)
wg.Add(1)
go Work1(messges, wg, "1")
wg.Add(1)
go Work2(messges, wg, "2")
monitorWorker(wg, messges)
messgesResponse := make(chan []*TestStruct)
go GetWorkerValues(messges, messgesResponse)
headers := make([]*TestStruct, 0)
headers = <-messgesResponse
fmt.Printf("len > %s\n", len(headers))
for i:=0;i %s\n", headers[i].Name)
}
}
func monitorWorker(wg *sync.WaitGroup, cs chan *TestStruct) {
go func() {
defer close(cs)
wg.Wait()
}()
select {
case <-time.After(2 * time.Second):
return
}
}
func Work1(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(1 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(1 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
func GetWorkerValues(cs <-chan *TestStruct, response chan<- []*TestStruct) {
var val []*TestStruct
for header := range cs {
val = append(val, header)
}
response <- val
}
Thanks,
Abhi
--
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.
--
You received this message bec
Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get
timeout which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
>
> What do you see when you run it? I see:
>
>
>
>finished 1
>
>finished 2
>
> len > %!s(int=2) ç Using a string format for an int
>
>Name > 1
>
>Name > 2
>
>
>
> Ø Work 2 - have 3 second
>
>
>
> I’m not sure exactly what you are trying to do, but I suspect that
> changing “messges” to hold 2 items might make it work.
>
>
>
> messges := make(chan *TestStruct, 2)
>
>
>
> I’m guessing, but I suspect that you didn’t realize that if Work1 runs
> first, then Work2 will block since the channel is full (or until you close
> it).
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [mailto:
> golan...@googlegroups.com ] *On Behalf Of *
> desaia...@gmail.com
> *Sent:* 2017 January 08, Sun 01:23
> *To:* golang-nuts
> *Subject:* [go-nuts] Multiple goroutine timeout for waitgroup not working
>
>
>
>
>
> Can you please help to correct below program where timeout not seems
> working
>
>
>
> Work 1 - have 1 second
>
> Work 2 - have 3 second
>
> Total Timeout - 2 sec
>
>
>
> program wait for entire 3 seconds and return both values rather than value
> from Work 1
>
>
>
> Program >
>
>
>
> package main
>
>
>
> import (
>
> "fmt"
>
> "time"
>
> "sync"
>
> )
>
>
>
>
>
> type TestStruct struct {
>
> Name string
>
> }
>
>
>
> func main() {
>
>
>
> wg := &sync.WaitGroup{}
>
> messges := make(chan *TestStruct, 1)
>
>
>
> wg.Add(1)
>
> go Work1(messges, wg, "1")
>
> wg.Add(1)
>
> go Work2(messges, wg, "2")
>
>
>
> monitorWorker(wg, messges)
>
>
>
> messgesResponse := make(chan []*TestStruct)
>
> go GetWorkerValues(messges, messgesResponse)
>
>
>
> headers := make([]*TestStruct, 0)
>
> headers = <-messgesResponse
>
>
>
> fmt.Printf("len > %s\n", len(headers))
>
>
>
> for i:=0;i
> fmt.Printf("Name > %s\n", headers[i].Name)
>
> }
>
> }
>
>
>
>
>
>
>
> func monitorWorker(wg *sync.WaitGroup, cs chan *TestStruct) {
>
> go func() {
>
> defer close(cs)
>
> wg.Wait()
>
> }()
>
>
>
> select {
>
> case <-time.After(2 * time.Second):
>
> return
>
> }
>
>
>
> }
>
> func Work1(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
> string) {
>
>
>
> defer wg.Done()
>
>
>
> v1 := new(TestStruct)
>
> v1.Name = tokenNumber
>
> time.Sleep(1 * time.Second)
>
>
>
> message <- v1
>
> fmt.Printf("finished %s\n", tokenNumber)
>
> }
>
>
>
> func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
> string) {
>
>
>
> defer wg.Done()
>
>
>
> v1 := new(TestStruct)
>
> v1.Name = tokenNumber
>
> time.Sleep(1 * time.Second)
>
>
>
> message <- v1
>
>
>
> fmt.Printf("finished %s\n", tokenNumber)
>
> }
>
>
>
>
>
> func GetWorkerValues(cs <-chan *TestStruct, response chan<- []*TestStruct)
> {
>
> var val []*TestStruct
>
>
>
> for header := range cs {
>
> val = append(val, header)
>
> }
>
>
>
> response <- val
>
> }
>
>
>
>
>
> Thanks,
>
>
>
> Abhi
>
> --
> 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.
Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
Thanks for the reply Sairam
Problem is if I change Work2 time => 3 sec then that work should get
timeout but program still returning it
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Rgds,
Abhi
On Sun, Jan 8, 2017 at 1:39 PM, Sairam Kunala
wrote:
> The ran the code on play, seems to come out within 2 seconds.
>
> https://play.golang.org/p/yZIAvXI8IX
>
> On Sun, Jan 8, 2017 at 12:53 PM, wrote:
>
>>
>> Can you please help to correct below program where timeout not seems
>> working
>>
>> Work 1 - have 1 second
>> Work 2 - have 3 second
>> Total Timeout - 2 sec
>>
>> program wait for entire 3 seconds and return both values rather than
>> value from Work 1
>>
>> Program >
>>
>> package main
>>
>> import (
>> "fmt"
>> "time"
>> "sync"
>> )
>>
>>
>> type TestStruct struct {
>> Name string
>> }
>>
>> func main() {
>>
>> wg := &sync.WaitGroup{}
>> messges := make(chan *TestStruct, 1)
>>
>> wg.Add(1)
>> go Work1(messges, wg, "1")
>> wg.Add(1)
>> go Work2(messges, wg, "2")
>>
>> monitorWorker(wg, messges)
>>
>> messgesResponse := make(chan []*TestStruct)
>> go GetWorkerValues(messges, messgesResponse)
>>
>> headers := make([]*TestStruct, 0)
>> headers = <-messgesResponse
>>
>> fmt.Printf("len > %s\n", len(headers))
>>
>> for i:=0;i> fmt.Printf("Name > %s\n", headers[i].Name)
>> }
>> }
>>
>>
>>
>> func monitorWorker(wg *sync.WaitGroup, cs chan *TestStruct) {
>> go func() {
>> defer close(cs)
>> wg.Wait()
>> }()
>>
>> select {
>> case <-time.After(2 * time.Second):
>> return
>> }
>> }
>> func Work1(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
>> string) {
>> defer wg.Done()
>>
>> v1 := new(TestStruct)
>> v1.Name = tokenNumber
>> time.Sleep(1 * time.Second)
>>
>> message <- v1
>> fmt.Printf("finished %s\n", tokenNumber)
>> }
>>
>> func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber
>> string) {
>> defer wg.Done()
>>
>> v1 := new(TestStruct)
>> v1.Name = tokenNumber
>> time.Sleep(1 * time.Second)
>>
>> message <- v1
>>
>> fmt.Printf("finished %s\n", tokenNumber)
>> }
>>
>>
>> func GetWorkerValues(cs <-chan *TestStruct, response chan<-
>> []*TestStruct) {
>> var val []*TestStruct
>> for header := range cs {
>> val = append(val, header)
>> }
>> response <- val
>> }
>>
>>
>> Thanks,
>>
>> Abhi
>>
>> --
>> 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.
RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 01:23
To: golang-nuts
Subject: [go-nuts] Multiple goroutine timeout for waitgroup not working
Can you please help to correct below program where timeout not seems working
Work 1 - have 1 second
Work 2 - have 3 second
Total Timeout - 2 sec
program wait for entire 3 seconds and return both values rather than value from
Work 1
Program >
package main
import (
"fmt"
"time"
"sync"
)
type TestStruct struct {
Name string
}
func main() {
wg := &sync.WaitGroup{}
messges := make(chan *TestStruct, 1)
wg.Add(1)
go Work1(messges, wg, "1")
wg.Add(1)
go Work2(messges, wg, "2")
monitorWorker(wg, messges)
messgesResponse := make(chan []*TestStruct)
go GetWorkerValues(messges, messgesResponse)
headers := make([]*TestStruct, 0)
headers = <-messgesResponse
fmt.Printf("len > %s\n", len(headers))
for i:=0;i %s\n", headers[i].Name)
}
}
func monitorWorker(wg *sync.WaitGroup, cs chan *TestStruct) {
go func() {
defer close(cs)
wg.Wait()
}()
select {
case <-time.After(2 * time.Second):
return
}
}
func Work1(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(1 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(1 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
func GetWorkerValues(cs <-chan *TestStruct, response chan<- []*TestStruct) {
var val []*TestStruct
for header := range cs {
val = append(val, header)
}
response <- val
}
Thanks,
Abhi
--
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.
