We only ever use floor division (//) in the module.

When the Python Interpreter exits, it first attempts to join any
outstanding threads.  This is problematic if a server is created
as a top-level variable or referenced by a reference cycle, as join()
will hang.  This adds cleanup behavior to the server thread's join().

Notable Changes:
  -Convert all str types to byte types at cython layer (ascii encoding)
  -Use six for packages that have different names in Python2/Python3
  -By default, unit tests are compiled/run in Python2.7 and Python3.4
  -Ensure MACOSX_BUILD_TARGET is at least 10.7

This method will be used in tests that want to ensure before
proceeding that the system under test has progressed to the control
point.

Going forward we'd like to be able to test much larger numbers of RPCs
than the number of threads available to a test.

The underlying bug in Core that this test was written to isolate was
fixed weeks ago.

This code has been unsupported for more than six months.

Since the default behavior is quite sane, support just calling ssl_channel_credentials() without explicitly specifying ssl_channel_credentials(None, None, None).

This changes the pattern ssl_channel_credentials(server_crt, None, None) to ssl_channel_credentials(server_crt)

Signed-off-by: Christian Svensson <blue@cmd.nu>

Apparently Python can call arbitrarily deallocation code whenever its
allocator is invoked, which can cause output from gRPC core to stderr,
which can happen on the thread that is emptying the stderr pipe, thus
causing the stderr pipe to deadlock on itself.

Both have to do with the test runner's handling of the tests. With one
it's the read thread somehow outliving the other threads (e.g. with
ctrl-C). The other is due to a filled OS-level pipe's buffer causing a
block while code is still holding the GIL in some gRPC core function. We
can't empty the buffer from Python because the GIL is held, and the OS
can't unblock because it's waiting for the buffer to get cleared:
deadlock.