Skip to content
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

Fix Hanging On Input Read #15

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Fix Hanging On Input Read #15

wants to merge 5 commits into from

Conversation

Kovak
Copy link

@Kovak Kovak commented Jun 11, 2019

Just started working with this lib for a project I was on and was having segfaults, buffer overflows, and general hanging when trying to read my keyboard. Turns out there were a couple things wrong:

  1. When reading from midi, bufferSize was incorrectly being looked up as the third arg in a two arg list. In addition it was being decoded using the c -> erl encoding (enif_make_*) instead of the erl -> c (enif_get_*). The type was also being used incorrectly, should be a long instead of an int I believe.

  2. Pm_Read was being used incorrectly. It can return negative values if it errors out, these were not being handled and were just being used as if they were positive integers, resulting in massive allocation requests and segfaults when the array was then created with a near max int number (from the negative number wrapping around as an unsigned int). These errors are now properly caught and passed out to be logged.

  3. Even when the above 2 issues were fixed, the lack of a sleep in between polling loop was locking up my device. I saw another PR for this but I didn't like how it did the sleep in C-space as A. the usleep function is not guaranteed to be in every platform, and B. It makes the nif more complicated and instead of just exposing the portmidi API introduced client-side logic to it. I have instead used elixir's :timer.sleep and exposed the amount to sleep as configurable. In my testing even a 1 ms sleep seems adequate.

@thbar
Copy link
Collaborator

thbar commented Jun 22, 2019

Just a casual reader here. If I read correctly, point 3 is a different strategy to fix what's already described by @zenwerk in #13, but more configurable?

Also adding a comment right onto the PR.

messages = do_read(stream, @buffer_size)
Server.new_messages(server, messages)
case do_read(stream, @buffer_size) do
{:error, reason} -> Logger.debug("Error Reading Midi: #{reason}")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a thought - it would be nice to design a way to let the caller specify the behaviour when such a message happens (e.g. a configurable callback of some sort), maybe with a default implementation?

@olafklingt
Copy link

I use Kovak's version. not that I really tested it but it seems to be more stable. what holds you back from merging the pull request?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants