By the way, is there a place in the library already where you are setting a slot's event flag when something happens, such as when the token is inserted or removed? If so, I can just look at that. Otherwise I will need to add a struct of my own. I can hunt through the code but if you have any pointers that would help.
Thanks, Carl On Wed, 14 Jul 2004 15:55:31 -0700, Carl Youngblood <[EMAIL PROTECTED]> wrote: > 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
