Re: [go-nuts] Re: Does current GC move object now?

2021-03-15 Thread Ian Lance Taylor
On Sat, Mar 13, 2021 at 10:26 PM rmfr  wrote:
>
> 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?

Yes, exactly.  There are special rules for syscall, and the Go project
promises that syscall will keep working, including pinning pointers,
and internal pointers, that are passed to syscalls.

Ian


> 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.

-- 
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/CAOyqgcUBUgw55HMMDp68mSZPhHCyRBjoL9di%3DGffrUBmB_L6bQ%40mail.gmail.com.


[go-nuts] Re: Does current GC move object now?

2021-03-13 Thread rmfr
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.