Carbon ReceiveNextEvent 和辅助线程
想象一个跨平台库，它必须创建自己的窗口，而不依赖于 WinForms/GTK#/WPF/MonoMac/etc（这是 OpenTK（如果有人感兴趣的话）。
事情是这样的：Windows 和支持 X11 的 Unices 支持（或可以使用）多个事件循环，每个线程一个。这意味着 (a) 您可以为每个线程创建一个窗口并让它们独立工作，(b) 您可以在一个线程上运行 WinForms（或 GTK#、WPF...）窗口并在另一个线程上打开 OpenTK 窗口，不受干扰。
现在，据我所知（诚然是有限的），Carbon 不支持这一点。操作系统事件仅传递到“主”事件循环，所有辅助线程都运行在烟雾中（即，ReceiveNextEvent 始终返回 eventLoopTimedOutErr 并且找不到任何事件）。 OpenTK 本身可以克服这个限制，没有问题，但这给尝试将 OpenTK 与不同工具包（例如 MonoMac）混合以呈现配置窗口的应用程序带来了一个有趣的问题。
有两个选择：
- 放弃这个疯狂的想法，并禁止将 OpenTK 与不同的工具包混合（不好）。
- 拿起一把战斧，砍掉碳，使其屈服（好）。
这是你进来的时候：你能想出任何方法来完成这项工作吗？想象一下以下场景：
- 线程#1（主线程）运行我们自己选择的一些初始化代码并生成第二个线程（我们可以自由修改它）。
- 线程 #1（主线程）打开本机窗口并运行 RAEL 循环 (RunApplicationEventLoop)。尽管如有必要，我们仍然可以安装计时器来运行我们的代码，但它超出了我们的直接控制范围。
- 线程 #2（辅助线程）打开一个 OpenTK 窗口，该窗口立即挂起（事件仅传递到线程 #1，而 ReceiveNextEvent 什么也得不到）。
是否可以过滤来自线程 #1 的事件并根据需要将它们传递给线程 #2？ CF 能帮上忙吗？ Mac OS X 的高手们，请帮忙！
（编程语言并不重要，使用您熟悉的任何语言。我更喜欢基于 Carbon 的解决方案，但 Cocoa 也可以正常工作。）
Imagine a cross-platform library that has to create its own windows without relying on WinForms/GTK#/WPF/MonoMac/etc (this is OpenTK in case anyone is interested).
Here is the deal: Windows and X11-capable Unices support (or can work with) multiple event loops, one on each thread. This means (a) you can create one window per thread and have them work independently and (b) you can run a WinForms (or GTK#, WPF, ...) window on one thread and open an OpenTK window on a different, without interference.
Now, to the best of my - admittedly limited - knowledge, Carbon does not support this. OS events are only delivered to the "main" event loop and all secondary threads run on fumes (that is, ReceiveNextEvent always returns eventLoopTimedOutErr and doesn't find any events). OpenTK itself can work with this limitation, no problem, but this poses an interesting problem to applications that try to mix OpenTK with a different toolkit (e.g. MonoMac) to present a configuration window.
Two options:
- abandon the idea as crazy and disallow mixing OpenTK with different toolkits (bad).
- pick a battle-axe and hack Carbon into submission (good).
Here is were you come in: can you think of any way to make this work? Imagine the following scenario:
- Thread #1 (main) runs some initialization code of our own choosing and spawns a second thread (we can modify this freely).
- Thread #1 (main) opens a native window and runs a RAEL loop (RunApplicationEventLoop). It goes out of our direct control, although we can still install timers to run our code, if necessary.
- Thread #2 (secondary) opens an OpenTK window that promptly hangs (events are only delivered to thread #1 and ReceiveNextEvent gets nothing).
Is it possible to filter events from thread #1 and deliver them to thread #2 as necessary? Could CF somehow help here? Gurus of Mac OS X, please help!
(Programming language doesn't matter, use anything you are familiar with. I'd prefer a Carbon-based solution but Cocoa would work just fine.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将事件从一个线程传递到另一个线程应该可以正常地传递事件。棘手的部分是，许多与 UI 相关的 API 都不是线程安全的，尽管核心 Carbon 事件处理是线程安全的。任何涉及更新控件和绘图的事情都应该在主线程上处理。这需要大量的来回，而且可能不值得尝试使其发挥作用。
Passing the events from one thread to another should work as far as just plain getting the events delivered. The sticky part is that a lot of the UI-related APIs are not thread safe, even though the core Carbon Event handling is. Anything that involves updating controls and drawing should probably be handled back on the main thread. That would require a lot of back-and-forth, and it may not be worthwhile to try to make it work.
看一下 Application.AddMessageFilter和 IMessageFilter 接口。您也许能够使用自定义逻辑拦截和转发消息。我过去（非常遥远的过去）曾使用过这种技术，但已经是很久以前的事了，我不记得与之相关的所有警告。我什至不确定消息过滤器是否会收到所有消息。在将它们发送到 IMessageFilter 之前，.NET 可能不会在幕后过滤掉它们，但值得一试。
Take a look at Application.AddMessageFilter and the IMessageFilter interface. You might be able to intercept and forward messages using custom logic. I have used this technique in the past (very distant past), but it has been so long ago that I do not remember all of the caveats that go along with it. I am not even certain that the message filter will receive all of the messages. .NET might not be filtering them out behind the scenes before sending them to the
IMessageFilter, but it is worth a shot.