Re: [libusb] [RFC] Deprecations and version changes

[Orin E. <ori...@gm...>]

On Sun, Jul 9, 2017 at 10:03 PM, Chris Dickens <
chr...@gm...> wrote:

> Hi,
>
> On Sat, Jul 8, 2017 at 1:57 PM, Peter Stuge <pe...@st...> wrote:
>
>> If not automatically full event handling, then yes, there would be a
>> callback to tell the consumer that it should call some event handling
>> function. I don't think that should be the default though, because
>> inconvenient.
>>
>
> So a dedicated thread inside libusb just to inform the application,
> through a registered callback, that something has happened and the
> application should call in to handle the events? This sounds like a
> horrible waste of a thread. The thread cannot be called an "event handling"
> thread because it doesn't actually handle anything, it just informs the
> application that something is pending. I do not see the benefit to this
> approach at all.
>

> Now, as to the notion of extending libusb to be able to provide an event
> handling thread internally (that actually fully handles events), this I
> support. I myself have an application written that creates a thread
> dedicated to calling libusb_handle_events() in a loop. I'm sure many
> applications out there do the same, and this is something that can fairly
> easily be provided by the library.
>


I'm fully on board with the latter - I too used a thread in a loop to
handle events, though I did use the thread to handle timeouts as well.

The former has the benefit of hiding both internal libusb resources _and_
the method used to determine something is pending, whether it be poll() or
WaitForMultipleEvents() - which is the point of the exercise - hiding OS
dependencies.  It would be trivial for a callback to write to a pipe or
socket to wake up a main context via poll() - and would likely eliminate
the need for most of the 16 libusb calls to do with poll fds/event handling.

I ask the question: "What is truly OS independent?"

    poll()              Absolutely not (*X only)
    Events              Absolutely not (Windows only)
    Semaphores          Not really (no anonymous semaphores on some OSs)
    Condition Variables Not really (recent addition on Windows)
    Callbacks           Yes!

So, I say go for callbacks.  Either or both methods mentioned would be
acceptable to me, but I must admit, if an event handling thread was
available in libusb, it is what I would use.