Andrei Tchijov wrote:
> Maybe I am missing something, but what are the benefits of
> "asynchronous API"? It is easy enough to start new thread for
> anything that needs to be done "asynchronously".
I assume you are talking about the libfprint API, not the fpusb one.
My answer: threading shouldn't be necessary - and as I will show with my
upcoming work, it isn't! I don't want to make something unreasonably
complex when it can quite easily done in a simple fashion.
> Could you please
> elaborate a little bit about why "asynchronous API" is so appealing?
The async API is only part of the reason for the development direction
here, but it is simply nice to have. It avoids having to create threads
in certain types of applications (e.g. GUIs) to call libfprint. In
almost all cases, threading an appliation adds a degree of complexity,
which is obviously avoided when you don't have to create threads.
It also allows more efficient integration with applications that sleep
on multiple event sources.
The more significant advantages of switching direction here are
expressed in terms of library internals.
For example, there currently is no way to cancel an ongoing enrollment
request. If we were to implement this in the current model, it would
involve forcing the application to have 2 threads calling into libfprint
simultaneously (one calling enroll, and another one trying to cancel the
request). Internally within the library, we would have to switch from
long/infinite USB timeouts to very short ones (to provide acceptable
response time for cancel requests) which will drain battery life. And
overall the implementation would just be hacky.
The external async API will allow us to offer a nice cancellation API,
but more importantly, the whole idea of cancellation is not possible
internally without being able to do async USB I/O, and that's the real
advantage here.
Also, by having drivers asynchronously drive the library, we can
implement more advanced features which would otherwise be quite a
nightmare. For example, finger resampling. When the user presses their
finger on the sensor, the first image that comes back isn't very good.
We want to capture a few images. But we also want to be aware that the
user may remove their finger at any time. Rather than massively
complicate the internal driver API, we can simply reverse the data flow:
the driver tells the library when a finger is present, informs the
library when an image is ready, and tells the library when a finger is
removed -- regardless of what the library and it's users are doing at
that point in time. It'll improve driver quality quite a bit.
There are other plus points too. Another one that jumps to mind will be
increased USB performance by queueing multiple URBs asynchronously. This
will decrease the inner-loop time for imaging, which will result in
further improved imaging performance from the authentec swipe devices.
At the end of the day:
- the library is more efficient
- more advanced features will be implemented, resulting in improved
user experience
- drivers will work better
- imaging will work better
- async API will be offered
- crucial missing functionality will be added
- integration into a wider range of applications will be easier
- for the people who still don't like the above, they can continue to
use the existing API (which will remain, maybe with some slight
modifications) - no big deal!
I am grateful for your porting efforts so far and am a little sad to
lose portability. But, I do not feel this is permanent. If someone will
step up and put effort into porting fpusb to other platforms, I *will*
help. Are you interested?
I just took a quick look at the libusb darwin port. It is only 1000
lines of code. It uses async I/O internally to offer libusb's sync
interface - so we already have a basis for async USB I/O. The only
missing piece is a pollable file descriptor, but if it is not
possible/straightforward to get one then you could relatively easily
emulate it with a thread and a pipe (I am prepared to be lenient and
allow non-Linux backends to create threads in the interest of portability).
The author of the libusb port - Nathan Hjelm - is still active and is
working on a darwin port of libusb. Maybe he would be interested in
helping too, but at the very least I imagine he would be happy to answer
questions about Darwin's userspace I/O API and the libusb/openusb
implementations.
Ultimately in addition to libfprint working again, you'll also have laid
the way for other projects. There is demand for a userspace USB I/O
library that does async USB I/O. I plan to stabilise and release mine
fairly soon, whereas the other alternative (openusb) does not seem to
have a release in sight. Even when both are released, fpusb will offer
more integration opportunities than openusb. In other words, I am
anticipating interest from other projects in using fpusb, so I am hoping
that porting efforts are inevitable and will be well-received :)
Daniel
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint
