On 29 May 2018 at 10:32, Loïc Gelle wrote:
> I don't understand what you mean by "not sustainable".
>>
>
> Not something you can keep in your codebase forever.
>
I think we're talking past each other on this point. Beyond being "not
elegant", I am not aware of Go dropping the support for calling
I don't understand what you mean by "not sustainable".
Not something you can keep in your codebase forever.
It really depends on who does it I would guess. It's very probably a couple
of months to get something that is bullet-proof and mergeable.
Is it on the roadmap for a future version of
On 29 May 2018 at 09:47, Loïc Gelle wrote:
> I agree that integrating C code into a Go codebase is somewhat inelegant.
>>
>
> Not only that, but it's not sustainable. It is more a hack than a feature.
>
I don't understand what you mean by "not sustainable".
>
> However, I'm not sure what you m
I agree that integrating C code into a Go codebase is somewhat inelegant.
Not only that, but it's not sustainable. It is more a hack than a feature.
However, I'm not sure what you mean by "implementation issues that are
specific to the language itself".
I mean that if you put static calls to
Hi Jeremie,
Thanks for your answer. I roughly estimated the overhead of calling an
empty C function (passing two integer arguments) from Go to 50ns per
call. Maybe not a big deal for a lot of use cases, but more
problematic if you want to trace performance-critical parts of Go like
its ru
On 4 May 2018 at 06:03, Loïc Gelle wrote:
> Hi,
>
> There has been a previous discussion on the mailing list about porting
> LTTng to Golang, about a year ago: https://lists.lttng.org/
> pipermail/lttng-dev/2017-June/027203.html . This new topic is to discuss
> more precisely about implementation
