Hello!
I have tested my integration with C++ project and found huge amount off issues related with golang .so implementation.
So when we create libgobgp.so we attach full Go's runtime to C++ application. It's not a simple code which could be called like native C .so file.
You could look on example application which linked to libgobgp:
16364 root 20 0 231M 19452 13708 S 0.0 0.1 0:00.03 │ └─ ./gobgp_api_client
16370 root 20 0 231M 19452 13708 S 0.0 0.1 0:00.00 │ ├─ gobgp_api_clien
16369 root 20 0 231M 19452 13708 S 0.0 0.1 0:00.00 │ ├─ gobgp_api_clien
16368 root 20 0 231M 19452 13708 S 0.0 0.1 0:00.00 │ ├─ gobgp_api_clien
16367 root 20 0 231M 19452 13708 S 0.0 0.1 0:00.00 │ ├─ gobgp_api_clien
16366 root 20 0 231M 19452 13708 S 0.0 0.1 0:00.00 │ ├─ gobgp_api_clien
16365 root 20 0 231M 19452 13708 S 0.0 0.1 0:00.01 │ └─ gobgp_api_clien
As you can see we have 5 threads from Golang and only single thread about app itself.
So it's not a problem itself. But Golang runtime redefine all signals and actions and broke popen (they related with SIGCHLD handler code used in pope) capability and daemoization code from my application.
I suggest to create native C library for encoding/decoding BGP structures.... But it's really complex... :(
Hello!
I have tested my integration with C++ project and found huge amount off issues related with golang .so implementation.
So when we create libgobgp.so we attach full Go's runtime to C++ application. It's not a simple code which could be called like native C .so file.
You could look on example application which linked to libgobgp:
As you can see we have 5 threads from Golang and only single thread about app itself.
So it's not a problem itself. But Golang runtime redefine all signals and actions and broke popen (they related with SIGCHLD handler code used in pope) capability and daemoization code from my application.
I suggest to create native C library for encoding/decoding BGP structures.... But it's really complex... :(