Callbacks and foreign threds

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Callbacks and foreign threds

Bill Schwab-2
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]


Reply | Threaded
Open this post in threaded view
|

Re: Callbacks and foreign threds

Chris Uppal-3
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