Go runtime vs autoreleasepools

[bradfitz]

Reading some of the macdriver code, like:

func (obj object) String() string {
        // TODO: some kind of recover to catch when this doesnt work                                                                                               

        pool := GetClass("NSAutoreleasePool").Alloc().Init()
        defer pool.Release()

        descString := obj.Send("description")
        utf8Bytes := descString.Send("UTF8String")
        if utf8Bytes.Pointer() != 0 {
                return C.GoString((*C.char)(unsafe.Pointer(utf8Bytes.Pointer())))
        }

        return "(nil)"
}

I don't see how that pool is able to do anything.

Reading https://developer.apple.com/documentation/foundation/nsautoreleasepool, it seems that it's very much thread-specific, but the code above (and other similar uses of Object.Autorelease, etc) don't seem to care about which rando thread the Go runtime throws them on and moves them to.

It seems there might be some runtime.LockOSThread usage missing?

I do see some, though:

crow5k:macdriver $ git grep LockOSThread
examples/_topframe/main.go:     runtime.LockOSThread()
examples/largetype/main.go:     runtime.LockOSThread()
examples/pomodoro/main.go:      runtime.LockOSThread()

Looking at those, it seems the requirement is that it's the caller's responsibility to only run code in goroutines that have been previously pinned to a thread?

[progrium]

I inherited most of the code in the objc package and still don't fully understand the interaction/use of autorelease pools from Go. But yes, my understanding is you'd need to run runtime.LockOSThread unless you know better and that it is the callers responsibility, but it's not documented because I haven't been able to fully experiment with all this to know and I've been hoping somebody will help.

[progrium]

In the documentation they talk about Application Kit having its own autorelease pool but its a little unclear what that means in this context. While there is a RunLoop class, it doesn't seem necessary and it might be NSApplication that sets all this up because I have seemingly run into objects cleaned up if they aren't Retained. There is also a mechanism in macdriver to dispatch code onto whatever thread Cocoa uses, which I had guessed was only necessary if calling code was run in a separate thread (which Go may do), which is why it was important to get that in.

What's actually going on and what should/could be done by macdriver vs the user and what needs to be known is still unclear so if you can help me figure it out I'd be super grateful. I'm also not an expert with the Objective-C runtime or Cocoa.

[progrium]

Also you can use dispatch package to run code in the main thread. But it's up to you to do that where necessary.