Int(uint(a) >> uint(b))
Is always ok, costs nothing, not a type safety issue.
On Sun, Sep 1, 2019 at 11:56 AM Steven Hartland
wrote:
> This has been changed in the upcoming 1.13 release, so you might want to
> try the latest release candidate.
>
>
> On 01/09/2019 19:03, Albert Tedja wrote:
>
>
Not true. The race detector does not detect certain cases and can overreport.
One the memory model becomes fully specified it may not be the case but if
would be very hard to implement something that didn’t work as I’ve said
Still you can just as easily change the other two accesses to be atom
This has been changed in the upcoming 1.13 release, so you might want to
try the latest release candidate.
On 01/09/2019 19:03, Albert Tedja wrote:
I am trying to perform some bitwise operators, but Go is not letting
me because the mask is an uint and the values are int. Setting the
mask to i
This is something I ran into a while back, and made a library for it,
though, I prefer not to spam the mailing list. Feel free to send me a dm
and I'll send you a github link if you are interested.
On Sunday, September 1, 2019 at 3:02:52 AM UTC-7, T L wrote:
>
>
>
> On Sunday, September 1, 2019
I am trying to perform some bitwise operators, but Go is not letting me
because the mask is an uint and the values are int. Setting the mask to int
will break the code since I am shifting bits right and left and prefer the
prefix 0 when shifting right, and if I am not mistaken, Go does not have
No such thing as a 'nil channel'. You are merely setting a variable to nil,
regardless what the previous content is.
It's just that Go allows you to receive from a nil variable if that
variable's type is a channel, in which case it blocks forever.
On Sunday, September 1, 2019 at 9:03:58 AM UT
You can simply validate it by run: go run -race main.go
for you program: https://play.golang.org/p/JRSEPU3Uf17
On Sunday, September 1, 2019 at 1:30:30 PM UTC-4, Robert Engels wrote:
>
> The memory model is pretty unspecified but they’re working on it. As a
> defacto behavior it is pretty hard to
The memory model is pretty unspecified but they’re working on it. As a defacto
behavior it is pretty hard to have what I stated not be the case.
> On Sep 1, 2019, at 9:46 AM, T L wrote:
>
> This is not true, at least no Go official documentation admits this.
>
>> On Sunday, September 1, 2019
hi,
I am looking for further details and explanations about the various
behaviors
associated with closed Vs nil channels.
I already read
https://stackoverflow.com/questions/43616434/closed-channel-vs-nil-channel
and other publications such as
https://medium.com/justforfunc/why-are-there-nil-ch
This is not true, at least no Go official documentation admits this.
On Sunday, September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote:
>
> That is incorrect. The atomic operations must exhibit the same happens
> before relationships as the mutex. If the mutex flushes the related cache
> lin
Btw, the removing of the GOMAXPROCS causes things to execute serially- which is
fine according to the spec - but it does make demonstrating certain concurrency
structs/problems pretty difficult.
> On Sep 1, 2019, at 7:05 AM, robert engels wrote:
>
> The point about ‘mu’ is valid. Rather than
The point about ‘mu’ is valid. Rather than ‘closed’, it should really be an
‘error’ given the situation - as it is more applicable to the operation
failures (as a black box IO component).
> On Sep 1, 2019, at 6:46 AM, Robert Engels wrote:
>
> As I pointed out in another reply, I am fairly cer
As I pointed out in another reply, I am fairly certain the atomic operations
must be valid in these cases due to the happens before relationship of them and
mutexes.
I don’t agree that returning the channel is a proper design, it breaks the
encapsulation. Technically mine could use multiple ch
That is incorrect. The atomic operations must exhibit the same happens before
relationships as the mutex. If the mutex flushes the related cache lines the
atomic load will pick it up.
> On Aug 31, 2019, at 10:55 PM, T L wrote:
>
>
>
>> On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Rober
Hi,
Thanks for the comments and the ideas :)
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.
I didn't know the com
On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wrote:
>
>
>
> On Sat, 31 Aug 2019 at 10:02, T L > wrote:
>
>>
>>
>> On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
>>>
>>>
>>>
>>> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
The reason you're wanting
On Sat, 31 Aug 2019 at 10:02, T L wrote:
>
>
> On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
>>
>>
>>
>> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>>>
>>> The reason you're wanting priority select is because you are shutting
>>> down the data channel preemptively
The problem seems to be that you're using runtime.GOMAXPROCS. The fact that
using GOMAXPROCS causes a deadlock is probably a bug, but it's an easy one
to work around - just don't call it :)
FWIW here's a version of your code that I'd consider a little more
idiomatic.
https://play.golang.org/p/ufL
18 matches
Mail list logo
