-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Typed keys #7
Comments
Looks like there are some serious issues with input events on OS X. I am not receiving events mouse events and experiencing deadlocks. You don't happen to know what commit started this behavior do you? |
Using the latest master commit on this Macbook Pro 10.9.4 I don't have the issues you mention as long as I don't use CFRunLoopGetCurrent() instead of CFRunLoopGetMain() on the callback. |
I found the source of the deadlock I am experiencing, but I am not sure it is cause of the problem you are describing. First, the dead lock is on the hook_control_mutex and is caused by a race condition between hook_callback.c#L248 and Now as far as the CFRunLoopGetCurrent() vs CFRunLoopGetMain() go, I am not sure what you are doing but maybe if I describe how the library works you can tell me how/why it is causing an issue. The library requires two runloops, one for the callback thread and the other is a Main RunLoop. The callback RunLoop (CFRunLoopGetCurrent) is pretty strait forward and is used to block the hooks pthread. The Main RunLoop (CFRunLoopGetMain) is required for the TIS functions in input_helper.c#L154 to prevent random thread safety issues like "TSMProcessRawKeyCode failed (-192)." Normally this wouldn't be a huge deal if we could use the LLVM blocks extension, but that is not available to this project for a number of reasons. So instead, I add my own observer to the main runlop in hook_callback.c#L177 and then signal and wait in hook_callback.c#L350 when a key typed event is required. The signal is picked back up in the hook_callback.c#L126 for processing and then a conditional is used to resume the hook thread. Do you have main RunLoop active? Did you stop the Main RunLoop started by the library? |
Thanks for the clarifications. As for the other issue, it happens to me even with fresh check out of the master branch (didn't stop the main runloop, so it should be up and running). However, every time I type I get:
So I checked that and I saw hook_callback.c#L335 returning NULL which according to the CFRunLoopCopyCurrentMode doc, indicates a not running loop and therefore never enters the key typed case. Then I played a bit by exchanging it for a CFRunLoopGetCurrent() but then it blocks there. I'll try to trace the main loop and see what happened to it. |
Deadlocks are fixed in the trunk for Darwin and X11. Based on what you described, it sounds like you forgot to explicitly call CFRunLoopRun() from main. I'll play around with a little more and see if I can duplicate the issue. |
Oh, yeah, perfect. Completely right. Porting the demo to only pthread's made me overlook that call. I will still try to move it to the darwin implementation. Thank you for pointing that out, for the deadlocks fix and this wonderful library. |
Awesome! Thanks for the bug report and I am glad you are finding the library useful. I added a small note to the demo to avoid confusion. |
In Mac 10.9.4 I'm seeing for every key event the message:
Due to CFRunLoopCopyCurrentMode returning NULL, which from the docs means that the main loop is not running although at least CFRunLoopRun is blocking on the other thread.
This is just affecting the key typed detection but it is annoying nevertheless ;)
The text was updated successfully, but these errors were encountered: