Lock the OS thread when acessing errors #41

2013-09-19T12:17:54-05:00

carlosmn commented

2013-09-19 12:17:54 -05:00

(Migrated from github.com)

The library stores error information in thread-local storage, which
means we need to make sure that the Go runtime doesn't switch OS
threads between the time we call a function and th time we attempt to
retrieve the error information.

@vmg this is what I was talking about in the other PR. It's either this or wrap every single function with our own C wrapper that copies the error.

The library stores error information in thread-local storage, which means we need to make sure that the Go runtime doesn't switch OS threads between the time we call a function and th time we attempt to retrieve the error information. @vmg this is what I was talking about in the other PR. It's either this or wrap every single function with our own C wrapper that copies the error.

carlosmn commented

2013-09-21 16:12:44 -05:00

(Migrated from github.com)

Since we can essentially have arbitrary C code compiled in, I'm wondering if it might be worth it to wrap each function with the help of a macro so we can call C.wrapped_config_get_string and have a deep-copied error object as an output parameter, as we're sure we won't switch threads while in C-land. It's a bit more malloc-y but it should be cheaper than locking the thread every single time we want to do anything.

Since we can essentially have arbitrary C code compiled in, I'm wondering if it might be worth it to wrap each function with the help of a macro so we can call `C.wrapped_config_get_string` and have a deep-copied error object as an output parameter, as we're sure we won't switch threads while in C-land. It's a bit more malloc-y but it should be cheaper than locking the thread every single time we want to do anything.

Sign in to join this conversation.

No reviewers