Reference:
http://libusb.6.n5.nabble.com/Shutting-Down-Handlers-Cleanly-td5662459.html

This may be worth some discussions in the libusbx since
libusbx will be where the main Windows development
happen.

On Wed, Apr 25, 2012 at 2:14 PM, Garret Kelly <g...@chromium.org> wrote:
>>> Calling libusb_exit on the associated context from another thread
>>> doesn't work, because the event handler will attempt to use the
>>> context object after its poll call is finished by the closing of
>>> the control descriptor.
>>
>> We could decide that this is a bug. Do you have ideas for a fix?
>
> What about starting a sort of chain-reaction from within libusb_exit.
> If the context kept a count of the number of handlers that were
> currently executing then libusb_exit would not need to perform the
> context cleanup. A given handler would receive a message on the
> control pipe indicating that it needs to exit, decrement the ref count
> and (if the ref count is not zero) send another message on the control
> pipe, waking the next handler up (itself never returning to the poll,
> thereby never consuming the message it just sent). If a handler is
> ever instructed to exit and finds that the reference count is zero, it
> knows that it is the final handler and can dispose of the context
> object.
>
> If (for some reason) another handler thread enters the handling loop,
> it will be disposed of later once it receives the control message to
> exit.
>
> I'm not sure how this will interact with using using an external set
> of pollfds, I'd need to think more on that.
>
>> Did you call libusb_close() on all devices after having set your
>> completed variable? Did this kick the event handler loop?
>
> Hmm, that's a very good idea. I'll attempt this approach tomorrow and
> report back. Thanks!
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Reply via email to