Hello, I'm struggling with the following use case and I'm not sure the solution lays in extending my code or bug Woute^H the unbound developers with requests.
In this case I'm talking about using libunbound in Go and the locking issues that can occur with wrt to the crypto library that is used. In Go you do not have control over the amount of OS threads the runtime uses. Go uses goroutines and N of those routines are mapped to an OS thread at any moment in time. So if I'm using libunbound in my Go code it would be a good thing to tell OpenSSL that it needs to use locking because I might use threads. However, with (lib)unbound: * I cannot (easily) detect at runtime which crypto library unbound uses * I do not link with a crypto library myself directly, so setting up the locking feels a bit strange * Also there is not thread_id in Go, so I cannot tell openssl this My feeling is that 'ub_openssl_lock_init' (in util/net_help.c) should be moved to libunbound, so that I can "just" call it from Go when I setup the library for Go use, but I might be wrong. How do other languages wrapping libunbound deal with this? - Grtz, --- Miek Gieben
signature.asc
Description: Digital signature
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
