Per-Ola Gustavsson wrote:
Btw, the libfprint "SSM: sequential state machine" is quite flawed. Why isn't there a normal message loop system and threading? Maybe glib style? I haven't looked deeply into poll.c but I have a hunch it's functionality should be reimplemented in a very different way.
The idea was to use "zero threads" (i.e. to only use the thread of the process calling into the library). Why go to the expense of having a whole thread for tiny USB transactions? I was working with some very low power systems at the time.
Having implemented it like that though, I'm not sure it was worth it, as you note the code didn't turn out particularly small or readable. The SSM could probably be implemented to be cleaner/better, or indeed maybe moving to synchronous code running in threads would be sensible.
vfs5011.c doesn't handle libusb async calls in a correct or polite manner. It hi'jacks the thread of libusb and fills it's stack with recursive calls and memory allocations. I believe this is causing race conditions and other anomalies,
libusb doesn't have a thread either, but that kind of code does indeed sound like it would be problematic.
Thanks Daniel _______________________________________________ fprint mailing list fprint@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/fprint
