This question is focused exclusively on the writer side.
So are you saying that this will also work (based
on https://go.dev/play/p/ZXMg_Qq3ygF )
mmapBufRaw[fSize-1] = 255// W1
(*mmapBufAtomic.Load())[0] = 42 // W2
How about this, would that work as a "everything before
On the write side, you write your mult-GB data using normal writes, then
atomic.Store for the final flag uint. On the read side, you use an
atomic.Load for the flag uint followed by regular loads for the remaining
multi-GB of data.
Reading a particular flag value ensures that the following loads
On Sat, Jan 21, 2023 at 2:06 PM TheDiveO wrote:
>
> When a go routine gets locked to an OS thread, does the Go runtime scheduler
> then stops interrupting this Go routine, so when this Go routine (or rather
> the thread) gets pinned to an exclusive CPU core can make use of real time
> prioritie
When a go routine gets locked to an OS thread, does the Go runtime
scheduler then stops interrupting this Go routine, so when this Go routine
(or rather the thread) gets pinned to an exclusive CPU core can make use of
real time priorities?
--
You received this message because you are subscribe
On Sat, Jan 21, 2023 at 12:11 PM Peter Rabbitson (ribasushi) <
ribasu...@gmail.com> wrote:
> On Saturday, January 21, 2023 at 7:48:12 PM UTC+1 bse...@computer.org
> wrote:
> On Sat, Jan 21, 2023 at 10:36 AM Peter Rabbitson
> wrote:
> Greetings,
>
> I am trying to understand the exact mechanics of
( apologies for the previous mangled message, re-posting from a saner UI )
On Sat, Jan 21, 2023 at 7:47 PM burak serdar wrote:
>
>
> On Sat, Jan 21, 2023 at 10:36 AM Peter Rabbitson
> wrote:
>
>> Greetings,
>>
>> I am trying to understand the exact mechanics of memory write ordering
>> from wit
On Saturday, January 21, 2023 at 7:48:12 PM UTC+1 bse...@computer.org wrote:
On Sat, Jan 21, 2023 at 10:36 AM Peter Rabbitson wrote:
Greetings,
I am trying to understand the exact mechanics of memory write ordering from
within the same goroutine. I wrote a self-contained runnable example with
On Sat, Jan 21, 2023 at 10:36 AM Peter Rabbitson
wrote:
> Greetings,
>
> I am trying to understand the exact mechanics of memory write ordering
> from within the same goroutine. I wrote a self-contained runnable example
> with the question inlined here: https://go.dev/play/p/ZXMg_Qq3ygF and am
>
Greetings,
I am trying to understand the exact mechanics of memory write ordering from
within the same goroutine. I wrote a self-contained runnable example with
the question inlined here: https://go.dev/play/p/ZXMg_Qq3ygF and am copying
its header here:
// Below is a complete example, with the qu
It sounds to me like you are trying to write linux code to load a .so file.
Not something I have done in a while, but since no one else has offered any
help, I will give you a few pointers.
I believe that syscall.LoadDLL is for Windows only, so that code *will not
work* at all in linux.
You
The error is correct. Your code says to import
"github.com/ethereum/go-ethereum/ethash"
but if you browse to https://github.com/ethereum/go-ethereum you'll see
there is no "ethash" subdirectory.
On Saturday, 21 January 2023 at 14:17:01 UTC ramki...@hotmail.com wrote:
> Example/Test Code:
Example/Test Code:
https://pastebin.com/PaeuHuJx
But I get the error
go run main.go
main.go:11:2: no required module provides package
github.com/ethereum/go-ethereum/ethash; to add it:
go get github.com/ethereum/go-ethereum/ethash
tt@ubuntu:~/go/src/testing$ go get github.com/ethereum/g
12 matches
Mail list logo