Hi Per-Ola, On Wed, Jan 14, 2015 at 7:02 PM, Per-Ola Gustavsson <[email protected]> wrote: > 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.
Not true. Did you hear anything about multiplexing and select/poll/epoll syscalls? >> 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. As far as I remember, Daniel is an original author of libusb. But maybe things changed since he stepped out from libusb development. Regards, Vasily > >> >> 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 _______________________________________________ fprint mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/fprint
