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.

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.

Ian

-- 
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/CAOyqgcXuHZWAkvWWu5DKR1aMAGQG26PRBvQz7UpSEsN81huq%2Bw%40mail.gmail.com.

Reply via email to