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

Reply via email to