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?
Пн, 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 -- Best regards, Savely Krasovsky _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel