IomgrEventEngine

[drfloob]

@ctiller

Timer-only implementation. Mutates, tracks, and shuttles EventEngine API calls to iomgr.

Performance caveats:

• for Cancel to return true/false, timers are registered in a hash set, which is guarded by a lock. init/cancel/run all require acquiring the lock.
• every timer init does a small heap allocation.

[ctiller]

I haven't done a super close review, but the basics look like a good start.

Going forward, we should fork the grpc iomgr timer code into iomgr_eventengine.
This will ultimately allow us to eliminate the hash table (and global mutex!) and the allocation.

Playbook:

1. Fork grpc iomgr code
2. The two uintptr_t's in TaskHandle become: a pointer to the (forked/renamed) grpc_timer object, and a sequence number
3. grpc_timer additionally adds a sequence number for the TaskHandle that's currently active
4. When allocating a timer object, we first check a free list, if it's empty we take an allocation of a new object; if the free list is not empty we take one object off the free list
5. When freeing a timer object we add it to a free list (this can be done entirely with atomics - for an example look in core_configuration.cc for the registration list) -- note that this means that these timer objects are never deallocated
6. When we need to 'look inside' a TaskHandle we compare sequence numbers of the handle and the timer object it points to, and iff they match we return the pointer, otherwise we do not (it's a stale pointer)

Now the majority of timers do not allocate, and there's no global choke point to synchronize around (if the free list becomes a contention point we can even shard that)

[drfloob]

Going forward, we should fork the grpc iomgr timer code into iomgr_eventengine.

That's the plan. This is very much a temporary thing that can unblock other EventEngine progress.

Now the majority of timers do not allocate, and there's no global choke point to synchronize around (if the free list becomes a contention point we can even shard that)

That's an excellent trick. I think I could do something like that using the current {ptr, aba_token} in this implementation too, but doing the iomgr code migration first makes more sense.

[drfloob]

I believe this is ready for review.

[ctiller]

This is a reasonable first step, and we know it's not a final design.
We know the follow-up actions to take, so let's keep taking those monotonic steps.

[drfloob]

The 5 failed tests are all unrelated known issues: XDS, timeouts, or infra flakes.