Asynchronity concerns
From fprint project
To an application developer, one desirable feature of a library you are considering using is that it offers asynchronous access. By this, I mean two things:
- It is thread safe - your application can call back into the library from different threads without problems, even if two threads are calling simultaneously
- It offers a non-blocking API where all functions return in constant time (i.e. they do not wait on any condition)
In it's current state, libfprint is not thread safe and does not offer a non-blocking API. The device I/O functions in the API it offers (e.g. enroll, verify) do block for extended periods of time. This is effectively forcing all GUI applications to create a new thread solely for libfprint so that the UI remains responsive while the fingerprint reader is in use. Additionally, we lack a major piece of functionality: there is no ability to cancel an ongoing request.
[edit] libusb and openusb
The reason that libfprint is inflexible like this boils down to the fact that libusb function calls are blocking and there is no non-blocking alternatives. On Linux, libusb uses usbfs and usbfs does offer ways of submitting USB transfers asynchronously, but libusb does not expose this functionality.
libusb is mostly a dead project, but there is a new project called openusb which forks it, and recent work has added an asynchronous API. After initial libfprint prototypes are completed we should move over to this, helping out with openusb development if needed.
[edit] Future design ideas
Ultimately, we want to continue to offer a synchronous blocking API because of it's simplicity and appropriateness in command line applications. However, internally this should be based on the async APIs and relevant wait conditions.
We'd want to offer some kind of asynchronous "start enrollment" function, and then libfprint would call back into the client application when it is ready to start enrollment, when it's ready for the next enrollment stage, etc.
The calling application would have to regularly call back into libfprint which would call back into openusb -- we'd require main loop integration. It should also be possible to ask openusb which file descriptors it is interested in, pass them onto the app, and then the app could only call us when something is happening on those file descriptors.
