Possible s_driver leaking path about eventcore HOT 4 CLOSED

@s-ludwig : For reference, here's what our server memory usage looked like for the past ~3 months:

We have two instances of our app running per server, and the OOM killer would play Russian roulette with them on a daily basis. The less-steep curve at the beginning was just because there was little to no load on the app. We deployed the fix in #179 yesterday.

from eventcore.

In our case this was a Timer dtor triggered by a GC cycle which was triggered by an allocation in one of our module ctors.

This sounds like an issue that needs to be fixed. Since unfortunately the GC ignores thread-safety when calling finalizers, it is a programming error to let the GC reap vibe.d objects. They need to be disposed explicitly from their owner thread before the last reference disappears.

There is some mitigation logic in vibe/core/internal/release.d, but it seems like that didn't work here for some reason.

from eventcore.

Looking at the code, scratch that, releaseHandle itself calls eventDriver, so that was probably the issue. It would be nice to change that to use some pure getter version of eventDriver in order to avoid creating unused event driver instances in utility threads, though.

from eventcore.

For reference, here's what our server memory usage looked like for the past ~3 months:

Definitely a great catch. I wonder whether the dub registry is affected by this, too.

I've also added tryGetEventDriver in #182 so that vibe-core can avoid creating unnecessary driver instances.

from eventcore.