[ Quoting <unbound-users+phil@spodhu> in "Re: [Unbound-users] Using libunboun..." ] > > Hmmmm, that would certainly help (and maybe hurt performance), but then I > > still > > don't have the proper thread locking in place.... > > You don't need it. You create a go-routine which uses channels for
If you say, 'You don't need it", of what locking and where do you talk about? The Go code can be relative lock free, but why can I get away with not telling OpenSSL (or NSS) that it is going to get called from threaded code? > runtime.LockOSThread() > defer runtime.UnlockOSThread() > // do Unbound setup This would be the point to "tell OpenSSL/NSS that it is going to get called from threaded code", No? > Synchronous with N OS threads (no Go switch) and C.ub_resolve() should > get things going, since the callbacks for async will basically need to > be handled carefully, since if memory serves Go doesn't expose channel > write to the C layer. Or am I wrong? You may be right, but I think you are talking about stuff one layer higher than I am. - Grtz, --- Miek Gieben
signature.asc
Description: Digital signature
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
