On Wed, Jan 14, 2015 at 3:11 AM, Daniel Drake <[email protected]> wrote: > 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.
"Zero threads" equals synchronous (and blocking) calls. Cannot be combinated with asynchronous calls. Usually easier. > > 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. > Nothing against the SSM really, could be a lot more helpful though keeping track of states (including idle). I guess you could abstract infinitely.... >> 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. So I put this nifty little function in fpi_log() (core.c): g_thread_self() I simply include it's return value in the debug output and I know which thread the code currently is running in. Here is my tweaked debug output: [3.336136]Th:0x1b3b050 vfs5011:debug [usbexchange_loop] Receiving 2368 bytes [3.336218]Th:0x1b3c810 vfs5011:debug [async_recv_cb] Happy with 2 Th:xxxx is the thread. The callback from libusb is in another thread, from my perspective libusb DOES have a thread. I want to leave that thread as fast as possible to avoid problems. > > Thanks > Daniel > > _______________________________________________ > fprint mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/fprint As a footnote, there is a problem with libusb_device_handle, I think my device resets itself, this invalidates the handle. I then get a -4 from libusb_open(). A workaround should be made in fprintd probably. Don't know if it would be feasible in libfprint. At least document it. Kind regards Per-Ola Gustavsson marsba.se _______________________________________________ fprint mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/fprint
