Hi,
On 20/11/2023 10:11, Savely Krasovsky wrote:
Thanks for the reply!
After few days I have found a major bug: a close and free client before stop()
successfully executes. After fixing this I didn't get any segfaults anymore.
Program survives very extensive tests. But after your reply I am in question
again... Sure, openvpn3 has single thread after Connect(), but Go still could
call Stop() or any other method from another thread. And still I didn't get any
issues at the moment. Should I rewrite it anyway?
Calling from different threads is not an issue.
Invoking multiple methods at the same time is.
If you call openvpn3 code from multiple threads, it may be better for
you to implement your own locking system "outside" of the library which
makes sure no more than one caller is running openvpn3 code at a given
moment.
Cheers,
Пн, 20.11.2023 в 9:55 Arne Schwabe писал(а):
Am 12.11.2023 um 14:16 schrieb Savely Krasovsky:
Hello!
I am trying to use OpenVPN3 with Golang SWIG binding. It works pretty nice, but
I have random segmentation faults without obvious reason. My current guess is
that Golang calls OpenVPN3 from various threads and library is not ready for
that sometime. Am I right? Documentation doesn't say a lot about threading.
If this is a case, I have two possible solutions:
1. Use OPENVPN_ENABLE_BIGMUTEX build flag (I am not sure I need that).
2. Move all calls to OpenVPN3 into single goroutine and use
runtime.LockOSThread().
Could you please clarify, should I get segfaults in that case or not and the
problems is unrelated.
Yes. The client is singlethreaded and expects to be called only from a
single thread. You can have multiple clients in multiple threads but all
our own software uses just a single thread for the client itself.
Arne
--
Antonio Quartulli
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
