Hello gophers,
We have just released go1.19rc1, a release candidate version of Go 1.19.
It is cut from release-branch.go1.19 at the revision tagged go1.19rc1.
Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.
Re
Hello, I tried your example and I got
"c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
$WORK\b001\_x002.o: in function `_cgo_d32036b73474_Cfunc_print':
/tmp/go-build/cgo-gcc-prolog:49: undefined referen
Well, in my case, only the writing goroutine should be able to have access
to the datastructure (to keep the invariants). So I think a mutex should do
the trick.
Indeed, it looks like transactions or a reimplementation of a UI
thread/event loop.
A concurrent hash=array mapped trie might indeed
Depends on if you “concurrent” readers or serialized interlaced ones.
It depends on you transaction semantics - eg dirty reads, etc.
It is fairly easy for readers to grab the read lock and the writer thread
(since they were added to a queue) to grab the write lock when it has work to
do.
Li
On Wednesday, 6 July 2022 at 11:33:29 UTC+1 ren...@ix.netcom.com wrote:
> As I said, make the mutating op simply record the desired op on a queue
> and process the serially on another thread. You are essentially
> implementing transactions.
>
But how do you protect tree *readers* from having
