Windows specific files (for both 64bit and 32bit) have _win32 suffix and are using GPR_WIN32 header guard.
Change this to _windows file suffix and GPR_WINDOWS header.

I worked on this last week and am working on it again this week.

On the new_invoke_api branch, I've pushed the latest C API changes. Please update the wrapping there, and we'll push it in one batch once all the wrappings are fixed.

We should write one.

This is better C89 style.

There are still lots of references in the ruby code to internal Google resources and documents. This should be removed / replaced.

If you run make && make install, the libraries will be stripped of their debugging symbols in the libs directory. This makes in-place debugging hard.

The "install" target should depend on strip to copy the files to a strip directory first.

This causes us to rely on the backup poller to get new connections established, which dramatically slows down SSL handshakes on implementations that rely on pollsets.

1. have the fixture supply the client/server cq_verifier
2. add something to the cq verifier to add metadata checks to particular events when they actually come in

We want to be able to configure a cq verifier to be able to say:
'whenever I get one of client_metadata_read, server_rpc_new, or finished, I expect these pieces of metadata to be present'

And we want the fixture to be able to configure this - for verifying oauth code.

This depends on a change in the core such that on binding 0, the server returns the actual port address that it bound

E.g, return all the information in the event as a Struct.

This is a catch all to gather thoughts on a more optimal completion queue implementation (the current implementation is very placeholder).

For each reported event we (minimally):

1. allocate an event structure
2. (atomically) increment and decrement a reference count
3. fill in a data structure
4. run an indirect call
5. lock the completion queue mutex
6. broadcast on the completion queue condition variable

A simple first pass on this would be to change 6. to a signal to avoid a thundering herd, and find opportunities to inline the allocations in 1. to within the call object (i.e. we know that in the common case we'll have at most one read and one write event in flight, and we know we'll need one finish event).

It may also be worth merging locks between the completion queue and the read lock on the call object. This would introduce the possibility of slightly higher contention, but my gut feel (needs data) is that the work performed under the read lock is minimal enough that merging it with the cq lock would result in a net gain.

A larger problem is the thread hops that can be incurred getting work from the network threads to the application. This will be especially important to solve for our lower latency transports. Is there a design that can merge polling and completion queue waiting in an elegant way? My first thought:

• create completion queues from channels
• restrict channels to communicate over only one transport type (or transports with equivalent polling mechanisms at best)
• have cq_next() on an empty queue start polling - when we finish the poll we run callbacks and then re-examine the queue
• this may need a mechanism to kick other pollers out if we end up with multiple pollers

The ruby unit tests fail when run on a docker image with an error 'ruby: __pthread_mutex_cond_lock_adjust...'
This is happening at the c-layer, and does not appear to be in any code directly wrapped by the ruby.

The failure can be repeated outside of test code by attempting to connect to non-existent addresses.
The ruby tests do this is some places, which is probably why they fail in this way.

iomgr currently uses a sharding mechanism where multiple pollsets may share kick-pipes.

This is unsafe: consider two threads with two separate pollsets sharing a kick pipe. The first thread is polling on pollset A. The second thread is about to poll on pollset B. A third thread tries to kick pollset B. That wakes up the first thread, which drains the pipe. Now thread 2 enters poll and never sees the wakeup.

It is possible to avoid this in principle by ensuring only the target of the wakeup does the drain, but we're probably better off just freelisting and dynamically assigning kick pipes to begin with.

On the new_invoke_api branch, I've pushed the latest C API changes. Please update the wrapping there, and we'll push it in one batch once all the wrappings are fixed.

Once #41 #42 and #43 are fixed.

Figure out a simple way how to continously verify that grpc is building alright on Windows. Nothing complicated yet, any trivial solution will do.

High level task to compile and test grpc library on Windows.

Currently the biggest blocker is the layer that works with sockets (needs to be rewritten to work on Windows).

Note - this task is completed when it's possible to obtain credentials and attach them to a request on GCE

Simply call grpc_call_invoke, and allow immediate queuing of reads and writes.

We need base64 for both auth/security and chttp2 with different options. However the chttp2 code base currently does not support decoding (but this is coming soon) and not the options needed for encoding.

The plan is as follows.
1 ctiller@ submits the base64 decode in chttp2
2 jboeuf@ moves it to support/base64 and adds the options needed for security/auth and adapts both the chttp2 and auth code.

Craig, your turn!

The log says only

E0111 11:20:49.549845985    5834 frame_data.c:70] Bad GRPC frame type 0x54

but gdb shows that I actually got "There was no service found for the uri requested.".

This error message is harder to read than it should be.

Create some very simple prototypes that demonstrate feasibility of using P/Invoke (or other applicable technology).
The windows grpc library is not ready yet, but I can start experiments with Mono (which supports .NET 4.5 which we are likely to target and also supports P/Invoke).

On the new_invoke_api branch, I've pushed the latest C API changes. Please update the wrapping there, and we'll push it in one batch once all the wrappings are fixed.

Let's choose a version, tweak its parameters, and settle on it for this project.

The API review process is in progress.

go/grpc-csharp-public-api

Nathaniel:
After calling server_shutdown which stops a server from accepting new RPCs and connections, wanting to know how many RPCs the server is still processing and wanting to be alerted when all RPCs are completed are reasonable requests for code using the GRPC C core to want to make.

If we decide not to do this, they could count how many GRPC_SERVER_RPC_NEW events they've accepted against how many GRPC_FINISHED events they've processed.

Craig:
The count of inflight requests is something I'd rather not expose: anything relying on it is inherently racy.

I propose changing grpc_shutdown to:
/* Begin shutting down a server.
After completion of this call, no new calls or connections will be admitted.
Existing calls will be allowed to complete.
When all calls have completed, emit a GRPC_SHUTDOWN_COMPLETE event with tag 'tag'. */
void grpc_server_shutdown(grpc_server *server, void *tag);

• ruby can only receive signals on the main interpreter thread, and can't receive signals when the ruby GIL is dropped
• by default rpc_server currently runs on the current thread, which will sometimes be the main thread
• update rpc_server so that it runs on a separate thread by default, and has a class method that should be called by the main thread that installs signal handler and waits for interrupts

It's no longer used.

This causes us to rely on the backup poller to get new connections established, which dramatically slows down SSL handshakes on implementations that rely on pollsets.

sprintf causes CRT security warnings under Microsoft C compiler. We want a cleaner solution, but gpr_asprintf isn't really suitable for the kind of usage here.

This is tracking issue to ensure that the implementation of cancellation works from the wrapped apis.

The run_tests.py script's CLanguage should load build.json and parse the list of the tests to run.

In build.json, the array targets can have objects with the following properties:

"c++" set to true or false; if not set, default to false.
"run" set to true or false; if not set, default to true.

So, the code should select the appropriate tests to run, based on the language tag, and based on the fact it's a test that needs to be run.

Note that we will probably need to extend the build.json file to include the notion of complex tests - aka, tests that run off a shell script or something similar, and that execute several binaries with arguments.

Currently math.proto and stock.proto are defined using "syntax=proto2".

• they're both currently defined in proto3
• math.proto has "required" fields

This has been a huge customer request (ok to use proto3 runtime)

There's an impedance mismatch with the grpc layer and it's the right thing to do anyway.