Using GC to allocate event driver results in trailing segfault about eventcore HOT 6 CLOSED

ping @Abscissa this may be something you've experienced.

from eventcore.

Hm... I take it back, it actually gets freed synchronously, but BEFORE the final GC. So it's guaranteed to segfault.

Like I said, I'm not sure exactly how to solve it. Perhaps you can check if any sockets/contexts are open, and if so, don't free it (and use C malloc to allocate the driver).

from eventcore.

I'm going to work on a potential PR to fix this. I think it actually can be done without leaving any lingering resources -- you just have to defer destruction of the class until all the resources are released. Still have to allocate on the C heap though.

from eventcore.

OMG, I just realized, this was fixed by @s-ludwig 11 days ago in #87. I've been looking at my local download of eventcore debugging this. So hey, thanks for fixing it before I even discovered it, that's some service! 😜

from eventcore.

BTW, for the PR I was going to write, I had conceived of having the release resources function calling dispose automatically if dispose was already requested, but delayed due to still having open FDs. You'd just need a callback of some kind in the drivers that need it.

from eventcore.

I was originally going to implement it that way, too, but figured that since the application is usually shut down anyway, and the case where just a thread is shut down is more difficult to support correctly, it was better to just emit a warning and leave the OS clean up the rest. Emitting a warning and shutting down the driver lazily would of course have been better, but the gain/effort ratio currently was just not high enough for me.

from eventcore.