device filtering support
Kustaa Nyholm
Kustaa.Nyholm at planmeca.com
Fri Feb 3 07:58:12 EST 2012
This mainly curiosity and not wishing to (not being competent to)
get involved in the substance of this thread there are couple
of things I'd like to be educated about, feel free anyone.
On 2/3/12 14:17, "Hans de Goede" <hdegoede at redhat.com> wrote:
> But Unix users are used to not having to think about
>multi threadedness, instead relying on a select based loop.
This seems to imply and equate Unix users with certain type of
application / usage. For me it is hard to think about
a program/application that has a graphical user interface
(and uses usb) which does not have multiple threads.
>
>So I think we need to make it really really really clear in the API docs
>that
>the device removed/added callbacks are called from a different thread, and
>add an option for Unix API users to disable this behavior.
Hmm ... for me in it looks pretty obvious that callbacks
(in the absence of any standardized way of evoking them in
the defining thread) are inevitable called from a different thread.
But maybe I'm missing somethig ... or am not a real unix programmer
at heart ;-)
>Of course the
>Unix API users need to use the pollfd "stuff" then to make sure the
>callbacks
>are called, but I think being able to this non multi-threaded is important
>for Unix users.
Ok, maybe I see the light here: is this pollfd "stuff" what I
described above as "standardized way of evoking callbacks in
the defining thread" ?
cheers Kusti
More information about the libusbx
mailing list