That usage of setjmp and longjmp are pretty much banned in modern C by every linter. You can only call setjmp/longjmp within the current call stack (at least that's my understanding) - intermixing the context switch to Go would not be correct.
Just have a wrapper on f2() that takes the setjmp address() and set it and call f2(). -----Original Message----- >From: p...@cpan.org >Sent: Dec 9, 2019 12:30 PM >To: Ian Lance Taylor <i...@golang.org> >Cc: golang-nuts <golang-nuts@googlegroups.com> >Subject: Re: [go-nuts] cgo & long jump > >On Monday 09 December 2019 10:18:26 Ian Lance Taylor wrote: >> On Mon, Dec 9, 2019 at 8:57 AM <p...@cpan.org> wrote: >> > >> > I would like to ask some technical question about cgo and long jumps. >> > >> > In Go I have written shared library which exports C API and therefore >> > can be called by other C applications. This my library is compiling with >> > cgo, more precisely via: go build -buildmode=c-shared -compiler gc >> > >> > Now I would like to call from my Go library some C function which may >> > call longjmp(). And setjmp() was already called by application which is >> > using my Go library. >> > >> > It is possible to call from Go C function which calls longjmp() which >> > jumps outside of that my Go library? What would happen with Go garbage >> > collector and "defer" code? >> > >> > To imagine, whole stack looks like this: >> > >> > +------------------------------------------+ >> > | C application | >> > | main(): | >> > | call setjmp() | >> > | call f1() from Go library | >> > | ... | >> > +------------------------------------------+ >> > | Go library with exported C f1() function | >> > | f1(): | >> > | do something in Go | >> > | call f2() from C library | >> > | ... | >> > | return from f1() | >> > +------------------------------------------+ >> > | C library with exported f2() function | >> > | f2(): | >> > | do something in C | >> > | if error call longjmp() | >> > | else return from f2() | >> > +------------------------------------------+ >> > >> > And if longjmp() is called then it jumps to main() where setjmp() was >> > called. So effectively f1() function (in Go) does not return. >> >> I'm pretty sure that won't work at all. Sorry. > >Hi Ian! Thank you for your answer. > >I was trying to find any resource on Internet about long jumps and >"import C" but neither in official Go documentation nor in any other >blog post is written about it. > >There are many resources how Go is (fully) compatible with C and can >call C functions, but absolutely zero information how it is implemented >nor what would happen with such core feature of C language as long jumps >or signals. > >> Certainly no Go deferred functions will be run. I don't think this >> would break the garbage collector as such, but I expect that it would >> break the Go scheduler. In the best case you'll be left with a >> dangling goroutine that will never be run and never go away. > >So should I interpret your answer as long jumps are not supported and >caller of C function from Go must ensure that called C function would >not call longjmp()? > > >And another interesting question, it is possible to call longjmp() from >Go code? To throw C exception back to the main C application. > >-- >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. >To view this discussion on the web visit >https://groups.google.com/d/msgid/golang-nuts/20191209183039.khrexxnpedzitepy%40pali. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/168169317.2354.1575919493589%40wamui-lola.atl.sa.earthlink.net.
