| |||
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
| Hello all: I am doing some work on the libusb project and also the hplip (hp ink jet driver project) and I have stumbled across something and need some expert opinion. I am attempting to improve the recoverability of both of these applications (e.g. press cancel in the middle of a scan), and their general performance. Since the communication is basically half-duplex, I am attempting to replace the asynchronous IO with synchronous IO in libusb. What I have found is that during certain exchange sequences, ReadPipeTO with a timeout specified (45000ms) returns immediately with kIOReturnSuccess but a read size of 0. How can this be? Could the printer be signaling a NAK, or some such thing, and ReadPipeTO is interpreting this as a valid read. How can I make ReadPipeTO continue to block until it really has some data, or the timeout expires? I also changed it to use ReadPipeAsync with no improvement - the callback shows success with 0 bytes read. The reads are on a bulk input pipe. Eventually the pipe does return some data, but until then the code basically hard spins looking for data. This causes two problems: performance - really drags down the cpu, and the timeout testing for real error conditions does not work properly (since the requests are handled as if they were read ok - just with no data). Thanks, Robert Engels |
_______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/usb/email@hidden This email sent to email@hidden
| Home | Archives | FAQ | Terms/Conditions | Contact | RSS | Lists | About |
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2007 Apple Inc. All rights reserved.