Master/Main branch borked?

[anthdm]

Simple clone of the current main branch on Go version 1.19.4.

Maybe I'm missing some hidden snowflake?

ZenQ git:(main) go run examples/simple/main.go
# github.com/alphadose/zenq/v2
./zenq.go:94:6: array length constants.CacheLinePadSize - unsafe.Sizeof(selectFactory[T]{}) (value of type uintptr) must be constant
./select_list.go:27:4: n.threadPtr undefined (type *node has no field or method threadPtr)
./select_list.go:27:17: n.dataOut undefined (type *node has no field or method dataOut)
./select_list.go:28:4: n.next undefined (type *node has no field or method next)
./select_list.go:35:6: invalid recursive type node
        ./select_list.go:35:6: node refers to
        ./select_list.go:36:18: "sync/atomic".Pointer refers to
        ./select_list.go:35:6: node
./select_list.go:47:4: n.threadPtr undefined (type *node has no field or method threadPtr)
./select_list.go:47:17: n.dataOut undefined (type *node has no field or method dataOut)
./select_list.go:50:15: tail.next undefined (type *node has no field or method next)
./select_list.go:53:13: tail.next undefined (type *node has no field or method next)
./thread_parker.go:25:18: invalid recursive type "sync/atomic".Pointer
        ./thread_parker.go:25:18: "sync/atomic".Pointer refers to
        ./thread_parker.go:25:27: parkSpot refers to
        ./thread_parker.go:25:18: "sync/atomic".Pointer
./select_list.go:53:13: too many errors

[alphadose]

@anthdm I am running the go 1.19.0 darwin/arm64, I cloned the latest main branch and for me go run examples/simple/main.go seems to be working
I have never encountered that error before but I would suggest trying to run the same command with go version 1.19

[anthdm]

@alphadose That worked! Thanks.

Another question: Is there any good approach on fetching multiple values from the buffer at once without having race conditions?

We probably can, but we need to check all the slots we fetched if commited and not busy? Or is there a hidden snowflake?

[alphadose]

We probably can, but we need to check all the slots we fetched if commited and not busy?

@anthdm Yes that is correct, we just need to modify the code so that it keeps reading until it hits SlotEmpty/SlotBusy and the atomic access shall prevent any race conditions from occurring