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

Rebase of PR 807: non-blocking behavior for next_result #962

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

Conversation

sodabrew
Copy link
Collaborator

Rebase of #807

/cc @osheroff

Ben Osheroff and others added 4 commits April 14, 2018 11:18
when actually preforming a multi-statement select with any non-trivial
components, the `next_result` call will block the ruby interpreter.
We fix this in two ways:

First, we wrap up the actual mysql_next_result call in a "no-gvl"
call so that the interpreter can do other work while next_result is
happening.  Second, we borrow a method from do_query and spin in a
select() loop on the mysql socket until the query is ready.  A quick
source dive into the underlying mysql source shows that next_result()
falls into the same path as mysql_real_query (cli_read_query_result), so
this should be a safe method.
Rather than including violite.h to be able to look into the net.vio structure
to call its has_data function pointer, we borrow the definitions of just two
functions that understand this structure.

The underlying client library may have pre-read the results from the next
query, so wait_for_fd would not be triggered. Instead we will ask whether
the net.vio structure has additional data that hasn't been parsed.

Hack: use knowledge of whether the connecti is SSL or not to call the
appropriate has_data function and pass net.vio as an opaque structure.

Definitions are from vio_priv.h
@sodabrew sodabrew added this to the 0.5.2 milestone Apr 14, 2018
@sodabrew sodabrew modified the milestones: 0.5.2, 0.5.3 Jul 4, 2018
@sodabrew
Copy link
Collaborator Author

sodabrew commented Jul 4, 2018

There are actually more possible states than my implementation accounts for. I'm not sure if there's a clean way to do this without the underlying methods exposed.

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

1 participant