Maybe the reason for such a strict rule on using cgo is just to take precautions if our GC moves object in the future? And at that time, the syscall implementation must be rewritten to add some codes to pinning the objects used by each syscall from being moved. Am I correct?
On Sunday, March 14, 2021 at 2:11:18 PM UTC+8 rmfr wrote: > I am watching the implementation of syscall `writev` from [here]( > https://github.com/golang/sys/blob/bd2e13477e9c63125302cd9da2d61879c6aa1721/unix/zsyscall_linux.go#L1641), > > and comparing it with the [proposal]( > https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md) > of cgo. I found the rule applies on cgo and syscall is inconsistent. > > If the object could be moved during GC, then the code to implement > `writev` is incorrect. Because GC could happen during the syscall and the > byte slices kernel is using has been moved! :-( > > If the object may not be moved during GC, then the code to implement > syscall `writev` is correct. But from the perspective of go runtime, cgo is > just a kind of special "syscall", then the rule applies to cgo now is far > too strict -- you simply couldn't call a C API like `writev` which takes > array of byte slices as input arg (because the rule applies on cgo now only > allow one input arg contains at most one go pointer). > > Maybe I have missed something, please correct me. Thanks a lot for your > patient and kindness :-) > -- 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/57c3f2e9-e28c-43e3-b765-b33434b6d1f5n%40googlegroups.com.
