Blair,
I've been trying to put OpenSSL to work, and hit a problem that got me to do the right Google search<g> to discover some functions that I probably need to be calling. As I read it, the library wants at least one callback that allows it to ask for a wait on an OS mutex, or to release the mutex: void win32_locking_callback(int mode, int type, char *file, int line) { if (mode & CRYPTO_LOCK) { WaitForSingleObject(lock_cs[type],INFINITE); } else { ReleaseMutex(lock_cs[type]); } } Before setting the callback, one apparently calls CRYPTO_num_locks() to learn how many different mutexes the library wants - that number sets the bounds for "type" above. That should be easy to do from Dolphin on startup, and to undo prior to shutdown. My concern is that a Dolphin callback would map back to the GUI thread, which would would not be good when doing a wait on the mutex :( Am I stuck? Another thought: I have the wrapper DLL that we discussed earlier. It wraps a few fuctions and subsequent error checking as atomic operations, allowing them to work correctly as overlapped calls - the error stuff has to be called on the same OS thread as "the" function, and the DLL was a simple way to ensure it. In the super dumb questions department, can my wrapper DLL provide the callback function? I'll check Petzold when I get home (the complete absense of same in my office is made possible by Dolphin - thanks!!!). I have a faint memory of lots of thunking/prologue/epilogue trickery that was so much fun in win3.x being unnecessary under win32, which might work to my advantage here. There is a description of the callbacks at http://www.openssl.org/docs/crypto/threads.html and I've included some of the sample code below. If you need or want to see more, you can grab the whole thing from www.openssl.org and search it for mttest.c. The "other callback" (for IDs) is apparently not needed on Windows because getpid() does what the library wants. Have a good one, Bill --------------------------------------------------- void thread_setup(void) { int i; lock_cs=OPENSSL_malloc(CRYPTO_num_locks() * sizeof(HANDLE)); for (i=0; i<CRYPTO_num_locks(); i++) { lock_cs[i]=CreateMutex(NULL,FALSE,NULL); } CRYPTO_set_locking_callback((void (*)(int,int,char *,int))win32_locking_callback); /* id callback defined */ } void thread_cleanup(void) { int i; CRYPTO_set_locking_callback(NULL); for (i=0; i<CRYPTO_num_locks(); i++) CloseHandle(lock_cs[i]); OPENSSL_free(lock_cs); } -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Bill Schwab wrote:
> My concern is that a Dolphin callback would map back to the GUI thread, > which would would not be good when doing a wait on the mutex :( Am I > stuck? I suspect that not only would you be stuck, you'd quite probably be deadlocked. > Another thought: I have the wrapper DLL that we discussed earlier. It > wraps a few fuctions and subsequent error checking as atomic operations, > allowing them to work correctly as overlapped calls - the error stuff has > to be called on the same OS thread as "the" function, and the DLL was a > simple way to ensure it. > > In the super dumb questions department, can my wrapper DLL provide the > callback function? I don't see why not, and it sounds like the right way to go. I have to do something similar to avoid problems talking to Java threads in JNIPort. It's all quite messy, but it seems to work OK. See http://www.metagnostic.org/DolphinSmalltalk/JNIPort/jni-helper.html and http://www.metagnostic.org/DolphinSmalltalk/JNIPort/threading.html if you're interested in the details. -- chris |
Free forum by Nabble | Edit this page |