使用 USB 和 CFRunLoopSource 的 Mac 示例代码
我正在尝试（重新）编写一个使用 USB 控制扫描仪的程序。我已经设置了 USBIOInterfaceInterface，因此我可以通过管道发送和接收消息。我成功同步调用 WritePipeTO 和 ReadPipeTO，但我想从扫描仪异步读取。
我尝试过使用 ReadPipeAsyncTO，但回调永远不会被调用，直到调用超时。原因似乎是我没有在某处注册回调。如果我在异步读取之后添加一个 CFRunLoopRun ，那么它似乎可以工作，但只能通过对 CFRunLoopRun 进行许多嵌套调用来实现，这不是一个好主意。
我已经看过这些函数：
err = (*usbInterfaceInterface)->CreateInterfaceAsyncEventSource(usbInterfaceInterface, &cfSource);
CFRunLoopAddSource(CFRunLoopGetCurrent(), cfSource, kCFRunLoopDefaultMode);
但我还没有弄清楚如何告诉源当该接口上发生某些事情时应该调用什么回调。当我刚刚创建源并调用 ReadPipeAsyncTO 时，直到超时才调用回调。
是否有相同的示例代码，以便我可以了解这些函数如何协同工作？
I'm trying to (re-)write a program that uses USB controlled scanners. I've got my USBIOInterfaceInterface set up, so I can send and receive messages over the pipes. I am successfully calling WritePipeTO and ReadPipeTO synchronously but I want to read from the scanner asynchronously.
I've tried using ReadPipeAsyncTO, but the callback never gets called until the call timesout. The reason Appears to be that I'm not registering the callback somewhere. If I add a CFRunLoopRun after the async read, then it appears to work, but only by having many nested calls to CFRunLoopRun, which can't be a good idea.
I've seen the functions:
err = (*usbInterfaceInterface)->CreateInterfaceAsyncEventSource(usbInterfaceInterface, &cfSource);
CFRunLoopAddSource(CFRunLoopGetCurrent(), cfSource, kCFRunLoopDefaultMode);
but I haven't figured out how to tell the Source what callback should be called when something happens on that interface. When I just create the source, and call the ReadPipeAsyncTO, the callback doesn't get called until timeout.
Is there same sample code somewhere so I can see how these functions are SUPPOSED to work together?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
调用 CFRunLoopRun 或其等效的 NSRunLoop 几乎总是表明您的程序架构错误。
听起来这会是一件非常痛苦的事情，但是如果您将其重写为，您的应用程序会好得多，并且可以使用 ReadPipeAsyncTO 和 WritePipeAsyncTO 函数来工作使用运行循环而不是当前拥有的任何手动循环。
Calling
CFRunLoopRun, or its NSRunLoop equivalent, is almost always a sign that your program's architecture is wrong.It sounds like it would be a terrible pain to do, but your app would be much better—and would work, using the
ReadPipeAsyncTOandWritePipeAsyncTOfunctions—if you rewrote it to use the run loop instead of whatever manual loop you currently have.