Mohamed, Please bear in mind that, Peter Stuge's conflicting statement with regards to the answer previously given by Xiaofan, and earlier myself, is from someone who is (was) a simple subscriber of libusbx, as well as the sole lead of a competing project, and is therefore not an official voice of the libusbx project, like Xioafan or myself. As such he should never have replied with a "Yes" statement, and this unfortunately renders things confusing for users like yourself, as it require us to waste time trying to clean up the mess.
As I tried to explain previously, this does not qualify as a bug. It is a conscious decision to limit libusbx with regards to a behaviour that we estimated at the time, and still estimate now, is most likely going to be indicative of a problem with the libusbx-based software being designed, and therefore shouldn't need to warrant additional development until we have a real-life case for it. Whenever one designs software (an ever-prodigal race against time), the decision to catter for a very unlikely case is usually trumped by the need to press on with other matters, and this is exactly what occurred there. Now, it is possible that with USB 3.0, maybe some people will feel that running 256 CONCURRENT transfers on Windows is fair game and that libusbx should allow it, in which case I don't see much of a problem raising the table boundary, but I'd still like to see a proper real-life scenario for having an unbounded number of fds, and I'm afraid I still don't see your usage qualifying as one. But let's say we were to remove that limit altogether and grow that table dynamically. Now what? You indicated that in about 15 seconds, the 256 fds currently provided by libusbx are going to be allocated. So what happens if you let your software run for weeks on end? At the very least, you'll find that libusbx "leaks" about 2KB/minute and that as lookups become more and more time consuming (especially if we "grow" that table), so you'll get data drops and other undesirable behaviour. Now, if you say that the need for 256+n fds is only during an initial burst, and that the transfers are going to decrease after that, so that previous transfers can be processed, then you should be able to provide us with an estimate of how many extra fds (n) you would need during this initial burst period (knowing that the more fds you have, the more sluggishly libusbx will behave). Do you have such an estimate? If not, then I would advise you, as Tim and Xiaofan have already pointed out, to try to determine what the limits of your software are going to be as, even if libusbx doesn't try to set limits, if you have no idea how much resources your application may consume, you are bound to run out of them eventually and will have to design/fix your software accordingly. If you provide us with an estimate of how much concurrent transfers your application actually requires, then should be in a better position to devise what we think will be the best approach to satisfy everybody. But UNLESS you are able to get such an estimate, you need to understand that asking for the underlying software to be limitless will pointless. If you find out that your software actually requires a limitless number of fds when it runs, you will have to fix or redesign it one way or another, and you should be mindful that all libusbx did here is tell you, ahead of time, that you will have to fix/redesign it. Finally, you also want to be mindful that something that works fine on Linux, but that, given your timings, is probably very close to the maximum rate such a system can handle, may end up not working on Windows even with the same hardware, as there might be more overhead there... Or maybe you just didn't let the software run long enough to realize it was allocating more and more resources? In other news, please be advised that Peter Stuge has now been banned from libusbx-devel. If you have an issue with that [remember that this is something I repeatedly notified this list may happen], I'll be happy to explain, for one last time, why his contributions to this list have been much more undermining than helpful, and why I am confident that not having to deal with Peter's scare tactics, contradicting opinions or desire to tag whatever he doesn't like from libusbx as a bug, will ensure that this list is better off and friendlier to new users. Also remember that you have plenty of opportunity to interact with Peter on the libusb-devel [1] or other mailing lists, so if you want to jump on the high horse of "unilateral censorship", please be my guest. Regards, /Pete [1] https://lists.sourceforge.net/lists/listinfo/libusb-devel ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
