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

[T L]

On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote:
>
> Yes, that is why the original code did not use a lock on the read but the 
> read of the flag was wrong. The version I posted in the other thread works 
> fine locally. time.Sleep() has problems in the playground 
>

You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ?
No no, it is not a good ideas to use mutex in write but atomic in read to 
avoid concurrently accessing the same value.
 

>
> On Aug 31, 2019, at 7:50 AM, T L > wrote:
>
>
>
> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote:
>>
>> If you comment out the read method then all threads will block. That is 
>> the the behavior of an unbuffered channel - a writer blocks until a reader 
>> is ready. Which is why you always need a valid reader running. Unless the 
>> channel is closed and then the writer will panic. 
>>
>> The code I provided is valid. 
>>
>
> In fact, if I comment out the write instead read part, the code will also 
> crash on all goroutines are blocked.
>  
>
>>
>> On Aug 31, 2019, at 2:40 AM, T L  wrote:
>>
>>
>>
>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote:
>>>
>>> You changed the Read() method incorrectly - it should be using the Read 
>>> lock, not the Write lock.
>>>
>>> Still, as I pointed out when I posted it, Play has a problem where it 
>>> aborts if all routines are sleeping (not just blocked), so you need to run 
>>> it locally.
>>>
>>
>> My fault. But it doesn't matter, for the Read method is never called (I 
>> commented it off).
>> It also crash locally for all goroutines are blocked.
>>  
>>
>>> -Original Message- 
>>> From: T L 
>>> Sent: Aug 30, 2019 12:05 PM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>
>>>
>>>
>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:


 Makes no difference in the code I posted as long as they all use 
 the same MultiWriterChannel. In fact, others can be late started, as they 
 will fail fast if the channel is already closed.

>>>
>>> https://play.golang.org/p/pcwIu2w8ZRb
>>>
>>> All go routines are blocked in the modified version.
>>>  
>>>
 -Original Message- 
 From: T L 
 Sent: Aug 30, 2019 11:13 AM 
 To: golang-nuts 
 Subject: Re: [go-nuts] An old problem: lack of priority select cases 



 On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
>
> I don't think so. Why do you think that is the case? The RWLock is 
> "fair" in the sense that once the 'closer' attempts to get the lock, it 
> is 
> guaranteed to get it (as the code is structured) - the subsequent readers 
> will queue behind the "writer = closer".
>

 How about unknown/random number of senders and readers?
  

>
> -Original Message- 
> From: T L 
> Sent: Aug 30, 2019 8:50 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>
> @Robert 
> I think there is a difference between the code of @Leo and you.
> In you code, the Wirte/Read/Close are all possible to block for ever.
>
> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
>>
>>
>> Oops. You are right. The original used two different methods Closed() 
>> and Read() and when I refactored I forgot to add the Read lock to the 
>> Read(). That's why you always have code reviews...
>>
>> -Original Message- 
>> From: T L 
>> Sent: Aug 29, 2019 6:25 PM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>
>>
>>
>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels 
>> wrote:
>>>
>>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
>>>
>>
>> Doesn't the Read method need to be guarded by the reader lock?
>>
>>  
>>
>>>
>>> It won’t run correctly in the playground because it terminates when 
>>> all routines are asleep - which happens during the test (not sure why 
>>> it 
>>> does this, as sleeping is different than a deadlock).
>>>
>>> It is probably less efficient, and less orderly than the other 
>>> example using WaitGroup but you get the idea I hope. It forcibly 
>>> terminates 
>>> the writers before they complete by design.
>>>
>>> On Aug 28, 2019, at 4:09 PM, Michel Levieux  
>>> wrote:
>>>
>>> One should also be careful regarding the conceptual demands he or 
>>> she is making.
>>> Having a shared resource (that is complex enough that it cannot be 
>>> atomically accessed or modified) means essentially that "having 
>>> multiple 
>>> writers being transparent to the readers", fundamentally, is not 
>>> possible.
>>>
>>> From the moment 

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

[Robert Engels]

Yes, that is why the original code did not use a lock on the read but the read 
of the flag was wrong. The version I posted in the other thread works fine 
locally. time.Sleep() has problems in the playground 

> On Aug 31, 2019, at 7:50 AM, T L  wrote:
> 
> 
> 
>> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote:
>> If you comment out the read method then all threads will block. That is the 
>> the behavior of an unbuffered channel - a writer blocks until a reader is 
>> ready. Which is why you always need a valid reader running. Unless the 
>> channel is closed and then the writer will panic. 
>> 
>> The code I provided is valid. 
> 
> In fact, if I comment out the write instead read part, the code will also 
> crash on all goroutines are blocked.
>  
>> 
>>> On Aug 31, 2019, at 2:40 AM, T L  wrote:
>>> 
>>> 
>>> 
 On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote:
 You changed the Read() method incorrectly - it should be using the Read 
 lock, not the Write lock.
 
 Still, as I pointed out when I posted it, Play has a problem where it 
 aborts if all routines are sleeping (not just blocked), so you need to run 
 it locally.
>>> 
>>> My fault. But it doesn't matter, for the Read method is never called (I 
>>> commented it off).
>>> It also crash locally for all goroutines are blocked.
>>>  
 -Original Message- 
 From: T L 
 Sent: Aug 30, 2019 12:05 PM 
 To: golang-nuts 
 Subject: Re: [go-nuts] An old problem: lack of priority select cases 
 
 
 
> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:
> 
> Makes no difference in the code I posted as long as they all use the 
> same MultiWriterChannel. In fact, others can be late started, as they 
> will fail fast if the channel is already closed.
 
 https://play.golang.org/p/pcwIu2w8ZRb
 
 All go routines are blocked in the modified version.
  
> -Original Message- 
> From: T L 
> Sent: Aug 30, 2019 11:13 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
> 
> 
> 
>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
>> I don't think so. Why do you think that is the case? The RWLock is 
>> "fair" in the sense that once the 'closer' attempts to get the lock, it 
>> is guaranteed to get it (as the code is structured) - the subsequent 
>> readers will queue behind the "writer = closer".
> 
> How about unknown/random number of senders and readers?
>  
>> 
>> -Original Message- 
>> From: T L 
>> Sent: Aug 30, 2019 8:50 AM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>> 
>> @Robert 
>> I think there is a difference between the code of @Leo and you.
>> In you code, the Wirte/Read/Close are all possible to block for ever.
>> 
>>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
>>> 
>>> Oops. You are right. The original used two different methods Closed() 
>>> and Read() and when I refactored I forgot to add the Read lock to the 
>>> Read(). That's why you always have code reviews...
>>> -Original Message- 
>>> From: T L 
>>> Sent: Aug 29, 2019 6:25 PM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>> 
>>> 
>>> 
 On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels 
 wrote:
 Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
>>> 
>>> Doesn't the Read method need to be guarded by the reader lock?
>>> 
>>>  
 
 It won’t run correctly in the playground because it terminates when 
 all routines are asleep - which happens during the test (not sure why 
 it does this, as sleeping is different than a deadlock).
 
 It is probably less efficient, and less orderly than the other example 
 using WaitGroup but you get the idea I hope. It forcibly terminates 
 the writers before they complete by design.
 
> On Aug 28, 2019, at 4:09 PM, Michel Levieux  
> wrote:
> 
> One should also be careful regarding the conceptual demands he or she 
> is making.
> Having a shared resource (that is complex enough that it cannot be 
> atomically accessed or modified) means essentially that "having 
> multiple writers being transparent to the readers", fundamentally, is 
> not possible.
> 
> From the moment itself when such a resource is shared, there must be 
> some sort of mecanism (that one using resources atomically usable) 
> that ensures the integrity of it.
> Maybe what you're talking about is having it 

Re: [go-nuts] playground - time.Sleep causes deadlock

[andrey mirtchovski]

see the "faking time" section here: https://blog.golang.org/playground

not sure if anything has changed since that article

On Sat, Aug 31, 2019 at 4:22 PM robert engels  wrote:

> Yes, the code runs fine locally. Reviewing the playground docs, it sees
> that at one point time.Sleep() was a no-op and it was changed. I am
> thinking that in the course of that change, they forgot to change the
> ‘deadlock’ detector.
>
> On Aug 31, 2019, at 5:17 PM, burak serdar  wrote:
>
> On Sat, Aug 31, 2019 at 4:13 PM robert engels 
> wrote:
>
>
> The code at https://play.golang.org/p/9ZdPVvwyaYK
>
> should not deadlock. But it reports:
>
>
> I had the same problem the other day. Code runs locally, but not on
> playground. It also had a sleep in a goroutine.
>
>
>
> fatal error: all goroutines are asleep - deadlock!
>
>
> But if you look at the stack traces, you see multiple routines (sampled)
> like:
>
> goroutine 1 [sleep]:
> runtime.goparkunlock(...)
> /usr/local/go/src/runtime/proc.go:307
> time.Sleep(0x3e8, 0x0)
> /usr/local/go/src/runtime/time.go:105 +0x1c0
> main.main()
> /tmp/sandbox327672725/prog.go:81 +0x140
>
> goroutine 5 [sleep]:
> runtime.goparkunlock(...)
> /usr/local/go/src/runtime/proc.go:307
> time.Sleep(0x1, 0x0)
> /usr/local/go/src/runtime/time.go:105 +0x1c0
> main.producer(0x430150, 0x40a0e0)
> /tmp/sandbox327672725/prog.go:49 +0x60
> created by main.main
> /tmp/sandbox327672725/prog.go:73 +0xe0
>
>
> These routines are asleep, not blocked. They will awake from sleep
> (eventually) - so there cannot be a deadlock.
>
> I am assuming this is a limitation of the Go playground back-end, but I
> can’t see it documented anywhere? Also, I’m not sure why this limitation
> would exist, since if all the routines are asleep or blocked, it is
> consuming no resources.
>
> Ideas?
>
> --
> 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/C7B46199-05EA-47C1-9594-200E2DD36F99%40ix.netcom.com
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAMV2RqpyK54ZsUJAPF%3D8Jk2GUjAXL%2B6E5-htX7R-wSuM_6MNVg%40mail.gmail.com
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/F957AAC7-A4F9-45D5-A80E-2BA788C6C721%40ix.netcom.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK4xykX%3D1vALy1GDwAicJpN05nKMM60R7WMz6MBg97%2BLT%3DGZBg%40mail.gmail.com.

Re: [go-nuts] playground - time.Sleep causes deadlock

[robert engels]

Yes, the code runs fine locally. Reviewing the playground docs, it sees that at 
one point time.Sleep() was a no-op and it was changed. I am thinking that in 
the course of that change, they forgot to change the ‘deadlock’ detector.

> On Aug 31, 2019, at 5:17 PM, burak serdar  wrote:
> 
> On Sat, Aug 31, 2019 at 4:13 PM robert engels  > wrote:
>> 
>> The code at https://play.golang.org/p/9ZdPVvwyaYK 
>> 
>> 
>> should not deadlock. But it reports:
> 
> I had the same problem the other day. Code runs locally, but not on
> playground. It also had a sleep in a goroutine.
> 
> 
>> 
>> fatal error: all goroutines are asleep - deadlock!
>> 
>> 
>> But if you look at the stack traces, you see multiple routines (sampled) 
>> like:
>> 
>> goroutine 1 [sleep]:
>> runtime.goparkunlock(...)
>> /usr/local/go/src/runtime/proc.go:307
>> time.Sleep(0x3e8, 0x0)
>> /usr/local/go/src/runtime/time.go:105 +0x1c0
>> main.main()
>> /tmp/sandbox327672725/prog.go:81 +0x140
>> 
>> goroutine 5 [sleep]:
>> runtime.goparkunlock(...)
>> /usr/local/go/src/runtime/proc.go:307
>> time.Sleep(0x1, 0x0)
>> /usr/local/go/src/runtime/time.go:105 +0x1c0
>> main.producer(0x430150, 0x40a0e0)
>> /tmp/sandbox327672725/prog.go:49 +0x60
>> created by main.main
>> /tmp/sandbox327672725/prog.go:73 +0xe0
>> 
>> 
>> These routines are asleep, not blocked. They will awake from sleep 
>> (eventually) - so there cannot be a deadlock.
>> 
>> I am assuming this is a limitation of the Go playground back-end, but I 
>> can’t see it documented anywhere? Also, I’m not sure why this limitation 
>> would exist, since if all the routines are asleep or blocked, it is 
>> consuming no resources.
>> 
>> Ideas?
>> 
>> --
>> 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/C7B46199-05EA-47C1-9594-200E2DD36F99%40ix.netcom.com.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAMV2RqpyK54ZsUJAPF%3D8Jk2GUjAXL%2B6E5-htX7R-wSuM_6MNVg%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F957AAC7-A4F9-45D5-A80E-2BA788C6C721%40ix.netcom.com.

Re: [go-nuts] playground - time.Sleep causes deadlock

[burak serdar]

On Sat, Aug 31, 2019 at 4:13 PM robert engels  wrote:
>
> The code at https://play.golang.org/p/9ZdPVvwyaYK
>
> should not deadlock. But it reports:

I had the same problem the other day. Code runs locally, but not on
playground. It also had a sleep in a goroutine.


>
> fatal error: all goroutines are asleep - deadlock!
>
>
> But if you look at the stack traces, you see multiple routines (sampled) like:
>
> goroutine 1 [sleep]:
> runtime.goparkunlock(...)
> /usr/local/go/src/runtime/proc.go:307
> time.Sleep(0x3e8, 0x0)
> /usr/local/go/src/runtime/time.go:105 +0x1c0
> main.main()
> /tmp/sandbox327672725/prog.go:81 +0x140
>
> goroutine 5 [sleep]:
> runtime.goparkunlock(...)
> /usr/local/go/src/runtime/proc.go:307
> time.Sleep(0x1, 0x0)
> /usr/local/go/src/runtime/time.go:105 +0x1c0
> main.producer(0x430150, 0x40a0e0)
> /tmp/sandbox327672725/prog.go:49 +0x60
> created by main.main
> /tmp/sandbox327672725/prog.go:73 +0xe0
>
>
> These routines are asleep, not blocked. They will awake from sleep 
> (eventually) - so there cannot be a deadlock.
>
> I am assuming this is a limitation of the Go playground back-end, but I can’t 
> see it documented anywhere? Also, I’m not sure why this limitation would 
> exist, since if all the routines are asleep or blocked, it is consuming no 
> resources.
>
> Ideas?
>
> --
> 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/C7B46199-05EA-47C1-9594-200E2DD36F99%40ix.netcom.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqpyK54ZsUJAPF%3D8Jk2GUjAXL%2B6E5-htX7R-wSuM_6MNVg%40mail.gmail.com.

[go-nuts] playground - time.Sleep causes deadlock

[robert engels]

The code at https://play.golang.org/p/9ZdPVvwyaYK 


should not deadlock. But it reports:

fatal error: all goroutines are asleep - deadlock!

But if you look at the stack traces, you see multiple routines (sampled) like:

goroutine 1 [sleep]:
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:307
time.Sleep(0x3e8, 0x0)
/usr/local/go/src/runtime/time.go:105 +0x1c0
main.main()
/tmp/sandbox327672725/prog.go:81 +0x140

goroutine 5 [sleep]:
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:307
time.Sleep(0x1, 0x0)
/usr/local/go/src/runtime/time.go:105 +0x1c0
main.producer(0x430150, 0x40a0e0)
/tmp/sandbox327672725/prog.go:49 +0x60
created by main.main
/tmp/sandbox327672725/prog.go:73 +0xe0

These routines are asleep, not blocked. They will awake from sleep (eventually) 
- so there cannot be a deadlock.

I am assuming this is a limitation of the Go playground back-end, but I can’t 
see it documented anywhere? Also, I’m not sure why this limitation would exist, 
since if all the routines are asleep or blocked, it is consuming no resources.

Ideas?

-- 
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/C7B46199-05EA-47C1-9594-200E2DD36F99%40ix.netcom.com.

Re: [go-nuts] How to execute a command using root?

[Ronny Bangsund]

On Saturday, August 31, 2019 at 3:14:28 PM UTC+2, Jakob Borg wrote:
>
> On 31 Aug 2019, at 12:33, Ronny Bangsund  > wrote:
>
>
> Digging through my vast mess of code, I found this function which sets the 
> real and effective user (Setreuid) of the calling process:
> func DegradeToUser(uname string) error {
>
>
> Doesn't this suffer from the issue of only affecting the current thread on 
> Linux, and hence not being safe to use from Go?
>
No idea if Setreuid() works any differently than Setuid(), but I wouldn't 
rule it out. Paranoia should be the default state :)
 

>
> Setting the uid/gid as part of starting a child process should be safe 
> though (https://golang.org/pkg/syscall/#Credential).
>
Yeah, using that with StartProcess() might be a better idea.

-- 
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/a5a93fdf-6079-44d7-a83a-3ebc2d4080d0%40googlegroups.com.

[go-nuts] Go module and local dependencies

[t hepudds]

 A few quick comments: 

1. Try 'go build ./...'  from the root directory of the module to build all the 
packages in the module.  'go build'  without any arguments is the same as 'go 
build .'  which means just build the current directory/package. 

2.  With only one go.mod, you should not need a 'replace'  to find local code 
in your own module. 

3.  Make sure you use the full import path in any import statements in your 
code when importing other packages, even when importing other packages in the 
same module.  The import path should always start with the module path. (The 
module path what you see on the 'module' line of your go.mod). 

 If that doesn’t help, you might need to share the exact error messages, along 
with the exact go.mod and exact import statements in question. 

(I am on mobile, so sorry this is brief). 

Regards,
thepudds

-- 
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/2990d337-6f1e-46ea-9874-84b8e3089590%40googlegroups.com.

[go-nuts] Go module and local dependencies

[Guillaume Lescure]

Hi,

I spend my day trying to build a new project in Go using the new Go module 
system.
I didn't succeed so I'm kind of upset because I never waste that much time 
for something that simple before.

The project : I try to use Go module only so no environment variable 
anywhere.
There are 1 library and 1 executable (both in Go) in 2 different local 
folders.

The library In /home/angryBoy/myLib :
- go.mod
- myLib.go
- otherPkg
|- otherPkg.go

go.mod :

> module xxx/myLib
>

myLib.go : its package name is "myLib" and it doesn't import "otherPkg"
otherPkg.go : its package name is "otherPkg" and it does import "myLib"

At this point if I build it : "$ cd myLib && go build"
it's seems to be ok but in fact, it doesn't compile otherPkg.go (I add a 
compilation error inside to be sure)

1) Why doesn't it compile everthing like before ? How can I fix that ?

The executable In /home/angryBoy/myBin :
- go.mod
- myBin.go

go.mod :

> module yyy/myBin 


myBin.go : its package name is "myBin" and it does import "xxx/myLib" and 
"xxx/myLib/otherPkg"

But it fail at compilation ("$ cd myBin && go build") because it doesn't 
reconize "xxx/myLib". So, after a long time, I find something about 
"replace" keyword in go.mod so :

go.mod :

> module yyy/myBin 

require xxx/myLib v1.0.0

replace xxx/myLib =>  /home/angryBoy/myLib


And this workaround kind of works for this specific import but it doesn't 
work for otherPkg. Moreover, if I add :

> require xxx/myLib/otherPkg v1.0.0

replace xxx/myLib/otherPkg =>  /home/angryBoy/myLib/otherPkg


It doesn't find the go.mod (of course there is not). But if I understand 
correctly it shouldn't have more than 1 go.mod in a repository.
2) Is the "replace" workaround the good way to allow local compilation ? If 
yes, how can I access my sub-package ?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/dc705f79-95ff-46f3-905c-54732eee1bac%40googlegroups.com.

[go-nuts] adding files to existing ZIP archieves

[lgodio2]

How do I use files in ...\src\archive\zip to add files to an existing 
archive file MyArchieve.zip ?? 

-- 
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/d01f1863-0a63-4bd2-9d8d-68bc0af5eda9%40googlegroups.com.

Re: [go-nuts] Help understanding mapping Go<->C structures across IOCTL's

[George Hartzell]

George Hartzell writes:
 > 
 > Quick summary, I'm trying to understand the Go structures that cgo
 > gives me, how they map back onto the C structures and why a Go struct
 > that doesn't quite match the cgo output seems to work anyway.
 > [...]

Ian gave me a lot of good things to chew on, but didn't answer the
main question about why the different versions of the `i2c_msg` struct
definition all seem to work.

For those of you who've been sitting on the edges of your seats
awaiting the answer...

It turns out that my assumption, that the `buf` pointer's alignment
requirements end up inserting padding automagically, seems to be true.

I convinced myself of this using the `structlayout` tools from
https://github.com/dominikh/go-tools.

Starting with this input file:

```go
package main

// #include 
import "C"

// This is what `cgo -godefs` generates
type ViaGoDefs struct {
addr  uint16
flags uint16
len   uint16
buf   *uint8
}

// This is what @tetsu-koba used
type FromTetsu struct {
addr  uint16
flags uint16
len   uint16
__padding uint16
buf   uintptr
}

// This is the result of using cgo as Ian suggested
type ViaCGo C.struct_i2c_msg
```

you can see that all of the structs have the same shape:

```
pi@raspberrypi:~/temper/go/structures $ structlayout -json structures ViaGoDefs 
| structlayout-pretty
++
  0 || <- ViaGoDefs.addr uint16 (size 2, align 2)
++
  2 || <- ViaGoDefs.flags uint16 (size 2, align 2)
++
  4 || <- ViaGoDefs.len uint16 (size 2, align 2)
++
  6 || <- padding (size 2, align 0)
++
  8 || <- ViaGoDefs.buf *uint8 (size 4, align 4)
++
--
++
 11 ||
++
pi@raspberrypi:~/temper/go/structures $ structlayout -json structures FromTetsu 
| structlayout-pretty
++
  0 || <- FromTetsu.addr uint16 (size 2, align 2)
++
  2 || <- FromTetsu.flags uint16 (size 2, align 2)
++
  4 || <- FromTetsu.len uint16 (size 2, align 2)
++
  6 || <- FromTetsu.__padding uint16 (size 2, align 2)
++
  8 || <- FromTetsu.buf uintptr (size 4, align 4)
++
--
++
 11 ||
++
pi@raspberrypi:~/temper/go/structures $ structlayout -json structures ViaCGo | 
structlayout-pretty
++
  0 || <- ViaCGo.addr structures._Ctype_ushort (size 2, align 2)
++
  2 || <- ViaCGo.flags structures._Ctype_ushort (size 2, align 2)
++
  4 || <- ViaCGo.len structures._Ctype_ushort (size 2, align 2)
++
  6 || <- padding (size 2, align 0)
++
  8 || <- ViaCGo.buf *structures._Ctype_uchar (size 4, align 4)
++
--
++
 11 ||
++
pi@raspberrypi:~/temper/go/structures $
```

Phew.

g.

-- 
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/23914.46306.691997.964218%40alice.local.

Re: [go-nuts] Help understanding mapping Go<->C structures across IOCTL's

[George Hartzell]

Ian Lance Taylor writes:
 > [...]
 > OK, that is true.  Since your program will be using cgo, even though
 > you aren't calling any C functions, it will be dynamically linked by
 > default.  You could try using "go build -ldflags=-extldflags=-static".
 > I don't know whether it will work.
 > 

To close the loop on this, using 

```
go build -ldflags=-extldflags=-static
```

does work, at least for the simple demo we've been discussing.

Onward!

Thanks again,

g.

-- 
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/23914.43161.264587.614979%40alice.local.

Re: [go-nuts] How to execute a command using root?

[Jakob Borg]

On 31 Aug 2019, at 12:33, Ronny Bangsund 
mailto:ronny.bangs...@gmail.com>> wrote:

Digging through my vast mess of code, I found this function which sets the real 
and effective user (Setreuid) of the calling process:
func DegradeToUser(uname string) error {

Doesn't this suffer from the issue of only affecting the current thread on 
Linux, and hence not being safe to use from Go?

(https://github.com/golang/go/issues/1435)

Setting the uid/gid as part of starting a child process should be safe though 
(https://golang.org/pkg/syscall/#Credential).

//jb

-- 
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/2B7ECBB8-89AE-48ED-AB08-9DB94902B050%40kastelo.net.

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

[T L]

On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote:
>
> If you comment out the read method then all threads will block. That is 
> the the behavior of an unbuffered channel - a writer blocks until a reader 
> is ready. Which is why you always need a valid reader running. Unless the 
> channel is closed and then the writer will panic. 
>
> The code I provided is valid. 
>

In fact, if I comment out the write instead read part, the code will also 
crash on all goroutines are blocked.
 

>
> On Aug 31, 2019, at 2:40 AM, T L > wrote:
>
>
>
> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote:
>>
>> You changed the Read() method incorrectly - it should be using the Read 
>> lock, not the Write lock.
>>
>> Still, as I pointed out when I posted it, Play has a problem where it 
>> aborts if all routines are sleeping (not just blocked), so you need to run 
>> it locally.
>>
>
> My fault. But it doesn't matter, for the Read method is never called (I 
> commented it off).
> It also crash locally for all goroutines are blocked.
>  
>
>> -Original Message- 
>> From: T L 
>> Sent: Aug 30, 2019 12:05 PM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>
>>
>>
>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:
>>>
>>>
>>> Makes no difference in the code I posted as long as they all use the 
>>> same MultiWriterChannel. In fact, others can be late started, as they will 
>>> fail fast if the channel is already closed.
>>>
>>
>> https://play.golang.org/p/pcwIu2w8ZRb
>>
>> All go routines are blocked in the modified version.
>>  
>>
>>> -Original Message- 
>>> From: T L 
>>> Sent: Aug 30, 2019 11:13 AM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>
>>>
>>>
>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:

 I don't think so. Why do you think that is the case? The RWLock is 
 "fair" in the sense that once the 'closer' attempts to get the lock, it is 
 guaranteed to get it (as the code is structured) - the subsequent readers 
 will queue behind the "writer = closer".

>>>
>>> How about unknown/random number of senders and readers?
>>>  
>>>

 -Original Message- 
 From: T L 
 Sent: Aug 30, 2019 8:50 AM 
 To: golang-nuts 
 Subject: Re: [go-nuts] An old problem: lack of priority select cases 

 @Robert 
 I think there is a difference between the code of @Leo and you.
 In you code, the Wirte/Read/Close are all possible to block for ever.

 On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
>
>
> Oops. You are right. The original used two different methods Closed() 
> and Read() and when I refactored I forgot to add the Read lock to the 
> Read(). That's why you always have code reviews...
>
> -Original Message- 
> From: T L 
> Sent: Aug 29, 2019 6:25 PM 
> To: golang-nuts 
> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>
>
>
> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels 
> wrote:
>>
>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
>>
>
> Doesn't the Read method need to be guarded by the reader lock?
>
>  
>
>>
>> It won’t run correctly in the playground because it terminates when 
>> all routines are asleep - which happens during the test (not sure why it 
>> does this, as sleeping is different than a deadlock).
>>
>> It is probably less efficient, and less orderly than the other 
>> example using WaitGroup but you get the idea I hope. It forcibly 
>> terminates 
>> the writers before they complete by design.
>>
>> On Aug 28, 2019, at 4:09 PM, Michel Levieux  
>> wrote:
>>
>> One should also be careful regarding the conceptual demands he or she 
>> is making.
>> Having a shared resource (that is complex enough that it cannot be 
>> atomically accessed or modified) means essentially that "having multiple 
>> writers being transparent to the readers", fundamentally, is not 
>> possible.
>>
>> From the moment itself when such a resource is shared, there must be 
>> some sort of mecanism (that one using resources atomically usable) that 
>> ensures the integrity of it.
>> Maybe what you're talking about is having it transparent in terms of 
>> code, in which case we both agree, but if you're looking for something 
>> transparent in essence, as in performance, logical construction and all 
>> the 
>> rest, I think there is a misunderstanding here: even if it was added in 
>> the 
>> language, there would be many many things going on under the hood, as it 
>> is 
>> already (and cannot really be otherwise) for channel use alone.
>>
>> 

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

[Robert Engels]

If you comment out the read method then all threads will block. That is the the 
behavior of an unbuffered channel - a writer blocks until a reader is ready. 
Which is why you always need a valid reader running. Unless the channel is 
closed and then the writer will panic. 

The code I provided is valid. 

> On Aug 31, 2019, at 2:40 AM, T L  wrote:
> 
> 
> 
>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote:
>> You changed the Read() method incorrectly - it should be using the Read 
>> lock, not the Write lock.
>> 
>> Still, as I pointed out when I posted it, Play has a problem where it aborts 
>> if all routines are sleeping (not just blocked), so you need to run it 
>> locally.
> 
> My fault. But it doesn't matter, for the Read method is never called (I 
> commented it off).
> It also crash locally for all goroutines are blocked.
>  
>> -Original Message- 
>> From: T L 
>> Sent: Aug 30, 2019 12:05 PM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>> 
>> 
>> 
>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:
>>> 
>>> Makes no difference in the code I posted as long as they all use the 
>>> same MultiWriterChannel. In fact, others can be late started, as they will 
>>> fail fast if the channel is already closed.
>> 
>> https://play.golang.org/p/pcwIu2w8ZRb
>> 
>> All go routines are blocked in the modified version.
>>  
>>> -Original Message- 
>>> From: T L 
>>> Sent: Aug 30, 2019 11:13 AM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>> 
>>> 
>>> 
 On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
 I don't think so. Why do you think that is the case? The RWLock is "fair" 
 in the sense that once the 'closer' attempts to get the lock, it is 
 guaranteed to get it (as the code is structured) - the subsequent readers 
 will queue behind the "writer = closer".
>>> 
>>> How about unknown/random number of senders and readers?
>>>  
 
 -Original Message- 
 From: T L 
 Sent: Aug 30, 2019 8:50 AM 
 To: golang-nuts 
 Subject: Re: [go-nuts] An old problem: lack of priority select cases 
 
 @Robert 
 I think there is a difference between the code of @Leo and you.
 In you code, the Wirte/Read/Close are all possible to block for ever.
 
> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
> 
> Oops. You are right. The original used two different methods Closed() and 
> Read() and when I refactored I forgot to add the Read lock to the Read(). 
> That's why you always have code reviews...
> -Original Message- 
> From: T L 
> Sent: Aug 29, 2019 6:25 PM 
> To: golang-nuts 
> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
> 
> 
> 
>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:
>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
> 
> Doesn't the Read method need to be guarded by the reader lock?
> 
>  
>> 
>> It won’t run correctly in the playground because it terminates when all 
>> routines are asleep - which happens during the test (not sure why it 
>> does this, as sleeping is different than a deadlock).
>> 
>> It is probably less efficient, and less orderly than the other example 
>> using WaitGroup but you get the idea I hope. It forcibly terminates the 
>> writers before they complete by design.
>> 
>>> On Aug 28, 2019, at 4:09 PM, Michel Levieux  
>>> wrote:
>>> 
>>> One should also be careful regarding the conceptual demands he or she 
>>> is making.
>>> Having a shared resource (that is complex enough that it cannot be 
>>> atomically accessed or modified) means essentially that "having 
>>> multiple writers being transparent to the readers", fundamentally, is 
>>> not possible.
>>> 
>>> From the moment itself when such a resource is shared, there must be 
>>> some sort of mecanism (that one using resources atomically usable) that 
>>> ensures the integrity of it.
>>> Maybe what you're talking about is having it transparent in terms of 
>>> code, in which case we both agree, but if you're looking for something 
>>> transparent in essence, as in performance, logical construction and all 
>>> the rest, I think there is a misunderstanding here: even if it was 
>>> added in the language, there would be many many things going on under 
>>> the hood, as it is already (and cannot really be otherwise) for channel 
>>> use alone.
>>> 
>>> As for the priority using selects, I think it's more of something to be 
>>> dealt with on the "user-side". There are many kinds of priority in 
>>> general, and trying to implement something in the language itself would 
>>> IMO 

Re: [go-nuts] How to execute a command using root?

[Ronny Bangsund]

On Saturday, August 31, 2019 at 10:07:59 AM UTC+2, Chris Burkert wrote:
>
> is there some code available to dig into that? I plan to do something 
> similar that a regular user process starts up a kind of a root broker which 
> starts several other processes as different users.
>
You would by necessity have to launch a root process, which then degrades 
to whichever user it should actually run as. It's a one-way operation, no 
backsies :)

Digging through my vast mess of code, I found this function which sets the 
real and effective user (Setreuid) of the calling process:
func DegradeToUser(uname string) error {
uid := syscall.Geteuid()
if uid == 0 {
u, err := user.Lookup(uname)
if err != nil {
return err
}

uid, err := strconv.Atoi(u.Uid)
if err != nil {
return err
}

gid, err := strconv.Atoi(u.Gid)
if err != nil {
return err
}

err = syscall.Setgid(gid)
if err != nil {
return err
}

err = syscall.Setreuid(-1, uid)
if err != nil {
return err
}
} else {
return errors.New(ErrorNotRoot)
}

return nil
}

An error string is the only thing missing (ErrorNotRoot), otherwise it 
should be complete.

Especially for the communication part I don’t have a good and secure idea 
> so far.
>
My hammer is gRPC if I need something with a little security. It's a bit 
convoluted initially, but allows authenticating via certificates. If you're 
running everything on one system there might be better ways,

-- 
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/46eebc67-ed8f-4f48-b27c-a9af81d22ac8%40googlegroups.com.

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

[T L]

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

 

>
>> 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 golang-nuts+unsubscr...@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.

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

[Jesper Louis Andersen]

On Thu, Aug 29, 2019 at 7:02 AM Leo Lara  wrote:

> Hi Michael,
>
> The way I always have seen "transparent" used in software engineering is,
> that the user of something (lirabry, service, framework, etc) can use it
> without knowing its internal details, just normally, and the magic is done
> in the thing used.
>
>
People use this in the opposite form at times. That is, a transparent data
structure is one where you know its internal representation (and can rely
on that in your part of the program). In contrast an opaque data structure
is abstractly encapsulated: even if you know its internals, you cannot get
at it. Thus the latter is the former and the former is the latter compared
to your use.

-- 
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/CAGrdgiVtfj5oPkVYHXROyayukq9S0owzOPxgnsc4pSdTTyn9jw%40mail.gmail.com.

Re: [go-nuts] How to execute a command using root?

[Chris Burkert]

Dear Kevin,
is there some code available to dig into that? I plan to do something
similar that a regular user process starts up a kind of a root broker which
starts several other processes as different users. Especially for the
communication part I don’t have a good and secure idea so far.
thanks - Chris

Kevin Chadwick  schrieb am Fr. 30. Aug. 2019 um 13:13:

> On 8/30/19 7:49 AM, Benjamin wrote:
> > Do anyone have any suggestions on this? Thanks
>
> Sudo is an option. I prefer to have a master root process that spawns
> workers
> processes that drop privileges via setegid...seteuid... syscalls to
> dedicated
> users for various tasks. Takes concurrency to the next level and organises
> your
> code, but it is more work. Also allows flexibility on chrooting that
> requires
> root (though I find OpenBSDs unveil more useful mostly but occasionally
> both).
>
> If you don't want a process to be taken down by a process group fatal then
> fork
> it separately via a startup shell script.
>
> --
> 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/8908b67e-d5d6-698b-bd54-f2c95fc2566f%40gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALWqRZr%3Da0APK%2Bv6CQ9S9ptXrT2ok0OssNH4Kj3kmwtbmED%2BrA%40mail.gmail.com.

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

[T L]

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?
 

>
> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/15b4b573-ee9c-4552-be78-84b303173ad7%40googlegroups.com.

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

[T L]

On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote:
>
> You changed the Read() method incorrectly - it should be using the Read 
> lock, not the Write lock.
>
> Still, as I pointed out when I posted it, Play has a problem where it 
> aborts if all routines are sleeping (not just blocked), so you need to run 
> it locally.
>

My fault. But it doesn't matter, for the Read method is never called (I 
commented it off).
It also crash locally for all goroutines are blocked.
 

> -Original Message- 
> From: T L 
> Sent: Aug 30, 2019 12:05 PM 
> To: golang-nuts 
> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>
>
>
> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:
>>
>>
>> Makes no difference in the code I posted as long as they all use the 
>> same MultiWriterChannel. In fact, others can be late started, as they will 
>> fail fast if the channel is already closed.
>>
>
> https://play.golang.org/p/pcwIu2w8ZRb
>
> All go routines are blocked in the modified version.
>  
>
>> -Original Message- 
>> From: T L 
>> Sent: Aug 30, 2019 11:13 AM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>
>>
>>
>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
>>>
>>> I don't think so. Why do you think that is the case? The RWLock is 
>>> "fair" in the sense that once the 'closer' attempts to get the lock, it is 
>>> guaranteed to get it (as the code is structured) - the subsequent readers 
>>> will queue behind the "writer = closer".
>>>
>>
>> How about unknown/random number of senders and readers?
>>  
>>
>>>
>>> -Original Message- 
>>> From: T L 
>>> Sent: Aug 30, 2019 8:50 AM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>
>>> @Robert 
>>> I think there is a difference between the code of @Leo and you.
>>> In you code, the Wirte/Read/Close are all possible to block for ever.
>>>
>>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:


 Oops. You are right. The original used two different methods Closed() 
 and Read() and when I refactored I forgot to add the Read lock to the 
 Read(). That's why you always have code reviews...

 -Original Message- 
 From: T L 
 Sent: Aug 29, 2019 6:25 PM 
 To: golang-nuts 
 Subject: Re: [go-nuts] An old problem: lack of priority select cases 



 On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:
>
> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
>

 Doesn't the Read method need to be guarded by the reader lock?

  

>
> It won’t run correctly in the playground because it terminates when 
> all routines are asleep - which happens during the test (not sure why it 
> does this, as sleeping is different than a deadlock).
>
> It is probably less efficient, and less orderly than the other example 
> using WaitGroup but you get the idea I hope. It forcibly terminates the 
> writers before they complete by design.
>
> On Aug 28, 2019, at 4:09 PM, Michel Levieux  
> wrote:
>
> One should also be careful regarding the conceptual demands he or she 
> is making.
> Having a shared resource (that is complex enough that it cannot be 
> atomically accessed or modified) means essentially that "having multiple 
> writers being transparent to the readers", fundamentally, is not possible.
>
> From the moment itself when such a resource is shared, there must be 
> some sort of mecanism (that one using resources atomically usable) that 
> ensures the integrity of it.
> Maybe what you're talking about is having it transparent in terms of 
> code, in which case we both agree, but if you're looking for something 
> transparent in essence, as in performance, logical construction and all 
> the 
> rest, I think there is a misunderstanding here: even if it was added in 
> the 
> language, there would be many many things going on under the hood, as it 
> is 
> already (and cannot really be otherwise) for channel use alone.
>
> As for the priority using selects, I think it's more of something to 
> be dealt with on the "user-side". There are many kinds of priority in 
> general, and trying to implement something in the language itself would 
> IMO 
> either be too specific compared to the nessecary time to do so or it 
> would 
> probably have a huge overhead on the "classical' use case of the select 
> construct.
> + the fact that it is apparently already possible using RWMutexes.
>
> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz  a 
> écrit :
>
>> Think of a channel as existing for the lifetime of a particular data 
>> stream, and not have it be associated with 

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

[roger peppe]

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


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 golang-nuts+unsubscr...@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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJhgacgdNrNCsEN_-oAPAbzLwq6fhakuvPjg3%3Dyg-VLTe1hkqQ%40mail.gmail.com.