Thanks for the tips. Actually the non-blocking one is really easy, because all it does is return immediately with either a CKR_OK if some slot's state has changed since the function was last called or a CKR_NO_EVENT if no slot's state has changed since the last call. It does not accept a callback.
The blocking version will be a little harder because I will need to wait for the async_TokenEventCallback function to trigger a pthread condition variable. The other option (looping while checking the status of the event flags and sleeping inbetween) would be an acceptable solution but less efficient. > Just make sure you are not creating threads if the application using the > P11 module specifies not to create threads. I noticed this behavior when I examined the source and I think that the library is not exactly doing what it should. So far this hasn't mattered because the only functions supported are synchronous. The PKCS11 spec says that the threading flags in C_Initialize are used to indicate whether or not "an application will be accessing Cryptoki through multiple threads simultaneously," not whether or not Cryptoki can use multiple threads to handle its own operations. Cryptoki would have to use multiple threads to support the C_WaitForSlotEvent function. Carl On Wed, 14 Jul 2004 18:27:48 -0400 (EDT), Chris Osgood <[EMAIL PROTECTED]> wrote: > On Wed, 14 Jul 2004, Carl Youngblood wrote: > > I was disappointed to discover that the Muscle PKCS11 libraries don't > > support what I would consider to be some pretty basic features listed > > in the PKCS11 spec. For example, the C_WaitForSlotEvent is the only > > The P11 module was created specifically to work with Mozilla and a limited > number of other applications. This has the unfortunate consequence of > making it not have all possible features. While the P11 module is written > to the specification as best as possible, if the features were not used > then they were not implemented. > > > The funny thing is, there are extension functions that provide this > > exact functionality (async_StartSlotWatcher et. al). It seems strange > > that the author went to the trouble of adding the feature but he > > didn't add a standards-compliant way to use it. > > Those functions are used internally to monitor the slots and were not > meant to be used by applications. It probably can be easily adapted for > that functionality however. > > > - Alter async_TokenEventCallback so that it also signals a pthread > > condition variable when called and sets the event flag an an internal > > array (explained below) for the slot whose state changed. > > Just make sure you are not creating threads if the application using the > P11 module specifies not to create threads. > > I think you're on the right track. The slot watcher stuff is already > managing insertion/removal events so I would look into that. > > The blocking version should be relatively easy to do. You could probably > do everything in the actual C_WaitForSlotEvent function and not even > bother with the other stuff. > > The non-blocking version would require a bit more work and hooking into > the slot watcher would probably be the easiest route. You might search > the code for "slot_status" (it's an array in P11_State) and take a look at > the "slot_TokenChanged" function in p11x_slot.c > > -- > // Chris _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
