Honestly, I cannot imagine practical application of it. But I understand that
Go tries to cover the case.
Thank you for your answers.
Hiroshi
Sent with Unibox
> On Jul 20, 2017, at 2:40 AM, Ian Lance Taylor wrote:
>
>
> On Wed, Jul 19, 2017 at 2:10 AM, Hiroshi Ioka wrote:
>>
>>
>>
On Wed, Jul 19, 2017 at 2:10 AM, Hiroshi Ioka wrote:
>
>> Before that change, newosproc0 was used when code built with
> -buildmode=c-archive did not use cgo.
>
> Is there any use case for shared libraries that don’t have exported
> functions?
Go code can use init functions to run code that does
Oh, I made a mistake. I mean shared => static/shared.
Sent with Unibox
> On Jul 19, 2017, at 6:10 PM, Hiroshi Ioka wrote:
>
>
> Thank you, I understand the situation mostly.
>
>
>> Before that change, newosproc0 was used when code built with
> -buildmode=c-archive did not use cgo.
>
>
Thank you, I understand the situation mostly.
> Before that change, newosproc0 was used when code built with
-buildmode=c-archive did not use cgo.
Is there any use case for shared libraries that don’t have exported functions?
Hiroshi
Sent with Unibox
> On Jul 19, 2017, at 7:40 AM, Ian Lan
On Mon, Jul 17, 2017 at 8:51 AM, 井岡裕史 wrote:
>
> c-share and c-archive enforce external linking.
> https://github.com/golang/go/blob/504deee6088c2448fc3e91c94a1ba69ec92fb7ef/src/cmd/link/internal/ld/config.go#L191-L196
>
> I think that external linking always use runtime/cgo because of following
>
I see. Thanks.
Sent with Unibox
> On Jul 18, 2017, at 1:03 AM, Aram Hăvărneanu wrote:
>
>
>> nitpick. os3_solaris.go.go set stack size by itself, instead of
>> using default one. is it intentional?
>>
>
>
>
>
> You mean why does it explicitely ask for a 2MB stack when 2MB stacks
> ar
> nitpick. os3_solaris.go.go set stack size by itself, instead of
> using default one. is it intentional?
You mean why does it explicitely ask for a 2MB stack when 2MB stacks
are the default? I can't remember the exact reason I did that but
it was a workaround for some sort of bug.
--
Aram Hăvăr
s/sys_solaris_amd64.go/os3_solaris.go/
--
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.
For more options, visit https://g
Thank you for your detailed answer.
1. I'm convinced. I understand that I don't have to consider the difference
in general.
> On Solaris there is no difference because they create threads the
same way in all cases.
nitpick. sys_solaris_amd64.go set stack size by itself, instead of using
default
> 1. Is there any noticeable benchmark difference between internal
> linking and external linking?
A benchmark testing what?
> IIUC, when I use external linking, runtime/cgo is used for OS thread
> creation. In that case Go doesn't allocate the system stack itself.
It's more complicated than tha
Hi, I have few questions out of curiosity.
1. Is there any noticeable benchmark difference between internal linking
and external linking?
IIUC, when I use external linking, runtime/cgo is used for OS thread
creation. In that case Go doesn't allocate the system stack itself.
So, I assume ther
11 matches
Mail list logo
