How about C calling Go

[Fabio Kaminski]

Hi folks,

   Go  working with C it's very easy and intuitive.. but since i didnt do my home work and hack the sources a little more..(its always a pleasure :)) how about, how to call Go code from C?

is there at least a way to compile a .so dinamic library , for load at runtime?

   Im coding a solution where i use C for OS interface, but i wanna be able to create all the "bussiness logic", or even.. "middle level" interfaces in Go.

i was cogitanting Lua for that matter to, but i think Go gains in a big system environment, with lots of pieces of code working together.

I saw some hacks about how to do it, but it was old.. and i saw some sources that may indicate that Go team have made a more easy and idiomatic way.

i just think to ask  before i did some "research" about go runtime, wich is a very good knowledge anyway..

but i think it wouldnt hurt.

Oh.. for start, i would like to create a C main, that includes a header from the stub.. with proper structs and methods..

by the way.. did'nt you missed to pass function pointer to methods.. or even be able to put callbacks in structs?  how about that :)

Thanks,

Fabio Kaminski

[Ian Lance Taylor]

Fabio Kaminski <fabiok...@gmail.com> writes:

> Go working with C it's very easy and intuitive.. but since i didnt do my
> home work and hack the sources a little more..(its always a pleasure :)) how
> about, how to call Go code from C?

Currently the main function must be written in Go. This could be
changed, and no doubt will be changed in the future, but changing it is
not simple.

You can of course have your Go main call a C function, and do most of
the work in C, and call back to Go where appropriate.

Ian

[Fabio Kaminski]

Thanks Ian!

Alright so two things left for me to ask.. 

Is there a way to do it, but its not simple? (can i doit myself, even if it requires deep knowledge, and patching some runtime code?) or there' s no way at all.

second. Can i at least (did'nt try yet) create a shared library? i should use go-gcc for that?

with a shared lib at least would be a possible solution , using dlopen() for instance.. not the best way, but at least possible... 

[Gustavo Niemeyer]

> Is there a way to do it, but its not simple? (can i doit myself, even if it
> requires deep knowledge, and patching some runtime code?) or there' s no way
> at all.

With deep knowledge and patching some code you can do pretty much
anything you please. :-)

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter

[Ian Lance Taylor]

Fabio Kaminski <fabiok...@gmail.com> writes:

> Is there a way to do it, but its not simple? (can i doit myself, even if it
> requires deep knowledge, and patching some runtime code?) or there' s no way
> at all.

Well, sure, you could do it if you dig into the code deeply enough. The
main issue is that you need to start the overall go runtime, which means
allocating stacks and running all the initializers. The go runtime will
not, of course, return, so if you want to use it in a reasonable way you
would have to have some mechanism by which the call to a Go routine
started the Go runtime in a separate thread.

> second. Can i at least (did'nt try yet) create a shared library? i should
> use go-gcc for that?

Yes, gccgo can create a shared library today. Actually, if you restrict
yourself to gccgo, it would be easier to start up the Go runtime.

> with a shared lib at least would be a possible solution , using dlopen() for
> instance.. not the best way, but at least possible...

Using dlopen doesn't make the real issues any simpler, they're still
there.

Ian

[Fabio Kaminski]

>Using dlopen doesn't make the real issues any simpler, they're still
>there

I understand your point.. i will call runtime anyway.. tricky!

But are you saying that runtime its in a forever loop? fire-and-forget?

that would restrict to launch "black boxes" and forget about it in another thread..

Or can i initialize the whole world , and start runtime, call some static method for instance, 

the method returns, runtime returns and i can pop out some things from stack?

(even if you has to do some assembly (ich) for that?!)

this is the last question, i sware :)

[ron minnich]

I'm completely lost on why you are trying to do this.

ron

[Fabio Kaminski]

On Fri, Feb 4, 2011 at 3:46 PM, ron minnich <rmin...@gmail.com> wrote:

I'm completely lost on why you are trying to do this.

ron

I have this high performance server in C, until i could change the whole thing with All-Go source, achieving the same performance( im sure it will happen fast), i wanna make a bridge to be able to have a more soft-productive-and-fast language, so it would be possible to develop the "real deal" with Go, while C code does what it does best, that is interact nativelly with the OS.

Maybe in that path, i can learn a little bit too.. but im just measuring the costs of this road i can take.. 

but anyway im sure that it's a nice characteristic to any language to have smooth interoperability with C..

suppose that i wanna to create a bind for gstreamer... and ok.. i can communicate fine with its api from Go.. 

but suppose that some event system flows in reverse.. and i have to bind a callback function, wich in this case, would be written in Go.. 

this is another thing, besides what im needing right now,  that comes in my mind, for the usefullness of these properties..

anyway, my need is to embed Go.. :)      

[ron minnich]

is it possible to contain the Go code in an RPC server and get your
seperation that way?

ron

[Fabio Kaminski]

it would work, but it would be trading memory latency for network latency. :s 

thinking in that way , it would be even better to stick with go's own infrastructure..

but i think that "embedded go" would have a poor performance.. 

technology.. why develop garbage collectors if it would be easiar to became a garbage collector.. :(   

[Ian Lance Taylor]

Fabio Kaminski <fabiok...@gmail.com> writes:

> But are you saying that runtime its in a forever loop? fire-and-forget?
> that would restrict to launch "black boxes" and forget about it in another
> thread..
>
> Or can i initialize the whole world , and start runtime, call some static
> method for instance,
> the method returns, runtime returns and i can pop out some things from
> stack?
> (even if you has to do some assembly (ich) for that?!)

I suppose in principle one could arrange for the runtime to return if
the function return and there were no goroutines running. That would
tend to be error-prone, though, as it's very easy to have a goroutine
sitting around waiting for something to happen, e.g., if you use a
timer.

Ian

[Matt Joiner]

I've a similar need, the inability to embed Go, and to use Go to
extend C eventually drove me back to Python and C. I also had much
difficult interpreting how to generate callbacks between C and Go.
Much work is required in this area before Go is a viable addition to
my development toolbox.

[Fabio Kaminski]

I think its a comfort idea to think that if i need more agressive optimization , i can write C code (whatever i want in the software cycle)

synce Go is aimed most at system programming.. its kind like assembly is to C.. we dont used to get into that level often.. but if you need, more optimization you can get it.. 

(note that if we all remembered, as the C compilers get better, we are not used to need assembly code anymore.. just very few cases)

I think Go was very well designed to have a great machine code..(it already does with so few years) but until the day of the state-of-the-art go compiler arrives, the one who can even beat C's .. (you get the idea already) 

or maybe you find that the bottleneck is the runtime.. not the optmized code.. 

And for this cases in the runtime aspect it would be good if we can get some "plugin" mechanism, for writing even non-portable code.. like if linux kernel XX has this new awsome user api for whatever.. and you wanna to get advantage of that, cause you dont care if your software can run even in toasters.. but you really need more horse-power to your applications.. 

moderns languages has so many chalenges to win.. :)

well i saw the function call graph for the runtime.. as Ian said, it will need modifications at least for this scenario.. cause its big..  the go code called its black-boxed... and i think this assembly parts will not be very helpful for this particular case..

i give up of this idea for now.. but i will continue my "readings" about the runtime.. while i practice more go code..

[Ian Lance Taylor]

Fabio Kaminski <fabiok...@gmail.com> writes:

> I think its a comfort idea to think that if i need more agressive
> optimization , i can write C code (whatever i want in the software cycle)
> synce Go is aimed most at system programming.. its kind like assembly is to
> C.. we dont used to get into that level often.. but if you need, more
> optimization you can get it..

Let's be clear, though: Go code can call C code just fine. And Go code
can call C code and that C code can call back into Go code. What does
not work at present is having a program whose main function is in C
which then wants to call Go code. That is, you can not embed Go code in
a C program.

I expect this will be fixed at some point--sooner if somebody starts
working on it.

Ian

[Mateusz Czapliński]

On Feb 6, 8:42 pm, Ian Lance Taylor <i...@google.com> wrote:

> Fabio Kaminski <fabiokamin...@gmail.com> writes:
> > I think its a comfort idea to think that if i need more agressive
> > optimization , i can write C code (whatever i want in the software cycle)
> > synce Go is aimed most at system programming.. its kind like assembly is to
> > C.. we dont used to get into that level often.. but if you need, more
> > optimization you can get it..
> Let's be clear, though: Go code can call C code just fine. And Go code
> can call C code and that C code can call back into Go code. What does
> not work at present is having a program whose main function is in C
> which then wants to call Go code. That is, you can not embed Go code in
> a C program.

Therefore, as long as one has access to the C code and can modify it,
I think it shouldn't be hard to rename the C main() to, say,
engine_main(), then wrap it with cgo and call from Go's main? Wouldn't
that do?

To keep the previous form factor available as well (although
separately), you could probably add a stub main() on the C side, which
would immediately call into engine_main(), but would be linked only in
the "Go-less" version of the product.

greetings
Mateusz Czapliński

[akashp...@gmail.com]

Im very interested in the static compilation of golang hence im quite sure it cannot be run  in C#.net4.5 feel free to correct if im wrong.