Steven Schveighoffer

Just directed here from a recent forum discussion. Reading Timon's example, it makes it difficult to justify this change. There are a couple options I can think of to address...

> you could do this I don't know if that works, though. When I declare an instance of `TmpBuffer`, it initializes it to 0s.

Right, but that just means you can't use your proposed workaround/solution. Again, is there a way around it?

@ntrel a possibility, but not practical for templates where you want everything inferred.

I'm not sure that solves the problem. For example, if you want `foo` to be inferred `@system` for any `@system` usage inside the lambda, but want to trust just the...

I'm having a similar issue. I've just now tried to make sure all sockets are closed so I don't get this error message. I believe I'm handling all the database...

Just to clarify, my messages say `streamSocket`, NOT `streamListen`, and I added the stopListening call, it doesn't fix it.

The underlying issue of WHY this happens is that the event driver is cleaning up synchronously, but items that will be cleaned up by the GC are still holding resources....

More info: it's the redis session store that is not closing. I'm "cheating" by using tupleof so I can close the driver sockets, but they still leak (I'm using instrumented...

OK, FINALLY! I figured out why this is happening. The redis session store doesn't provide a way to release unused connections, so as I said, I was cheating and using...