Initial implementation of mysql_use_result, accessible by setting :streaming => true when querying
Updated README to describe streaming
fixing vim's messed up indentation
Accidentally committed Gemfile.lock
Think I actually fixed indentation this time
Change mysql error detection strategy

Previous to this commit, some mysql connection errors were not detected
by the client.

This commit changes from implicit error detection via checking
mysql_field_count() to explicit detection via mysql_errno().

http://dev.mysql.com/doc/refman/5.0/en/null-mysql-store-result.html
Change :streaming to :stream
More stupid vim indentation
grrrrrrrr
attempt to avoid race condition with active connections
attempt to avoid race condition with active connections
add travis config to this branch
revert to using xmalloc/xfree for allocations

I've (re)read our usage of them and observed no bad interactions
with the Ruby GC and no need to use RB_GC_GUARD anywhere.

xmalloc() does error-checking for us, so we'll raise
NoMemoryError instead of a segfaulting when/if malloc() fails to
release memory.

xmalloc() may increase the frequency of GC invocation in MRI
because it bumps the malloc counter (and xfree() cannot
decrement it), but MRI 1.9.3+ users can set a higher
RUBY_GC_MALLOC_LIMIT to reduce GC frequency (or improve GC :P).
avoid potentially unsafe Ruby C API usage w/o GVL

Using StringValuePtr() /can/ potentially allocate a new String
object.  This allocation _currently_ impossible in our codebase,
but to prevent future/potential bugs from appearing, we'll
avoid StringValuePtr() (and any functions not explicitly
supported w/o GVL) in nogvl_* regions.
reacquire GVL before retrying on EINTR on connect

If signals are received, we must reacquire the GVL to let
(Ruby-level) signal handlers run.  Otherwise, it may be
impossible to effectively cancel/interrupt a slow connection
negotiation.

Fortunately, connecting to MySQL servers is rare and rarely
interrupted (or even interruptible) by signal handlers, so
maybe nobody noticed this bug.
revert to using xmalloc/xfree for allocations

I've (re)read our usage of them and observed no bad interactions
with the Ruby GC and no need to use RB_GC_GUARD anywhere.

xmalloc() does error-checking for us, so we'll raise
NoMemoryError instead of a segfaulting when/if malloc() fails to
release memory.

xmalloc() may increase the frequency of GC invocation in MRI
because it bumps the malloc counter (and xfree() cannot
decrement it), but MRI 1.9.3+ users can set a higher
RUBY_GC_MALLOC_LIMIT to reduce GC frequency (or improve GC :P).
avoid potentially unsafe Ruby C API usage w/o GVL

Using StringValuePtr() /can/ potentially allocate a new String
object.  This allocation _currently_ impossible in our codebase,
but to prevent future/potential bugs from appearing, we'll
avoid StringValuePtr() (and any functions not explicitly
supported w/o GVL) in nogvl_* regions.
reacquire GVL before retrying on EINTR on connect

If signals are received, we must reacquire the GVL to let
(Ruby-level) signal handlers run.  Otherwise, it may be
impossible to effectively cancel/interrupt a slow connection
negotiation.

Fortunately, connecting to MySQL servers is rare and rarely
interrupted (or even interruptible) by signal handlers, so
maybe nobody noticed this bug.
Fix issue with "should cache previously yielded results by default"

Was accidentally overwriting wrapper->numberOfRows on iterations after
first.
Fixed some icky ifs