Hi, I just started playing with javax.usb and ran into a situation where my CPU is reproducibly pegged at 100%. This thread:
<http://sourceforge.net/mailarchive/forum.php?thread_name=012601c7c6a6%2446545070%24c200010a%40Homer&forum_name=javax-usb-devel> reports a similar-sounding problem where "the machine grinds to a halt", but unfortunately doesn't describe any solution. It's the only other report I can find of such high CPU usage with javax.usb. Profiling my test class shows that the problem is caused (for me) by the while loop in the native function Java_com_ibm_jusb_os_linux_JavaxUsb_nativeDeviceProxy (defined in JavaxUsbDeviceProxy.c) - I see millions of JNI calls to the Java method com.ibm.jusb.os.linux.LinuxRequestProxy#isRequestWaiting() occurring. I'm no C hacker by any means, but the 'FIXME' comment is a bit of a giveaway and the argument of 0 passed to the usleep function seems to make the call pointless. Applying this diff makes the CPU more or less idle for me: $ cvs diff -cw JavaxUsbDeviceProxy.c Index: JavaxUsbDeviceProxy.c =================================================================== RCS file: /cvsroot/javax-usb/javax-usb-ri-linux/jni/JavaxUsbDeviceProxy.c,v retrieving revision 1.5 diff -c -w -r1.5 JavaxUsbDeviceProxy.c *** JavaxUsbDeviceProxy.c 19 Jul 2004 17:40:02 -0000 1.5 --- JavaxUsbDeviceProxy.c 28 Nov 2007 23:07:42 -0000 *************** *** 65,71 **** while (1) { /* FIXME - stop using polling! */ if ( loop_count > 20 ) { ! usleep( 0 ); loop_count = 0; } loop_count ++; --- 65,71 ---- while (1) { /* FIXME - stop using polling! */ if ( loop_count > 20 ) { ! usleep( 100000 ); loop_count = 0; } loop_count ++; I'm not quite sure why the function calls further down the while loop are executed 20 times for each call to usleep, nor what might be an optimal number of microseconds to sleep, but my first guess of 100000 seems OK. I'm also not sure why this wouldn't be a problem for _every_ javax.usb user, so I'm wondering if I'm only hitting it because of something I'm (not?) doing in my Java code or because of some problem with the USB device I'm talking to. But before heading off down either of those paths I'm wondering if anyone can offer an opinion on whether or not there is indeed a bug in the native code that's fixed by the diff above. -- Mark Scott [EMAIL PROTECTED] ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ javax-usb-devel mailing list javax-usb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
