About LockedConnection and its payload

Permalink: HTTP NNTP

Posted Sun, 14 Jan 2018 16:46:01 -0500

Reply

LockedConnection provides access to the underlying Connection via alias
this. And the alias this means LockedConnection can be implicitly
converted to the underlying Connection.

Am I correct in understanding that means it's possible for a
LockedConnection to go out of scope and become re-locked, but then
something that was already holding a reference to its underlying
Connection now has an "illegal" reference to a connection that's been
returned to the pool?

I take it this is something for user code to be careful to avoid?

Re: About LockedConnection and its payload

Permalink: HTTP NNTP

Sönke Ludwig

Posted Tue, 16 Jan 2018 15:13:27 +0100 in reply to Nick Sabalausky

Reply

Am 14.01.2018 um 22:46 schrieb Nick Sabalausky:

LockedConnection provides access to the underlying Connection via alias
this. And the alias this means LockedConnection can be implicitly
converted to the underlying Connection.

Am I correct in understanding that means it's possible for a
LockedConnection to go out of scope and become re-locked, but then
something that was already holding a reference to its underlying
Connection now has an "illegal" reference to a connection that's been
returned to the pool?

I take it this is something for user code to be careful to avoid?

Hm, you are right, I didn't really realize that. The __conn property
should probably just be changed to return a
vibe.core.concurrency.ScopedRef!Connection instead. That still leaves
a tiny hole, but until DIP1000 has landed, that should be the best
approximation.

Re: About LockedConnection and its payload

Permalink: HTTP NNTP

Steven Schveighoffer

Posted Tue, 16 Jan 2018 12:06:43 -0500 in reply to Nick Sabalausky

Reply

On 1/14/18 4:46 PM, Nick Sabalausky wrote:

LockedConnection provides access to the underlying Connection via alias
this. And the alias this means LockedConnection can be implicitly
converted to the underlying Connection.

Am I correct in understanding that means it's possible for a
LockedConnection to go out of scope and become re-locked, but then
something that was already holding a reference to its underlying
Connection now has an "illegal" reference to a connection that's been
returned to the pool?

Yes, but only if you specifically extract it. If you use auto
everywhere, then you shouldn't have a problem.

I take it this is something for user code to be careful to avoid?

This is the case with all reference counting wrappers. If you have
functions that accept an unwrapped object, you have no choice but to
extract it. But as long as you keep a local with that locked connection,
you should be OK.

-Steve