You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've recently bumped into an issue that affects how sink parameters behave in refc and which can have adverse effects on Chronos' (V4) futures: sink parameters can end up being passed by reference even when they should have been copied; i.e., even when there are later accesses to the same location at the caller.
This can in turn cause surprising behavior as the move in chronosMoveSink resets the location of the parameter, causing unexpected results:
import chronos
typeAnObject=objectofRootObj
inner: intlet fut =newFuture[AnObject]("myFuture")
var anObject =AnObject(inner: 42)
fut.complete(anObject)
echo fut.value.inner, ", ", anObject.inner
this prints "42, 0" when it should print "42, 42". If AnObject held a ref object in inner, you'd crash with a SIGSEV.
For async procs this seems to be less of an issue as capturing the parameter in a closure seems to get it copied somehow (I still don't get the whole mechanics), plus complete would typically only get called after user code is done so even accidental mutation is not the end of the world. But for code using "naked" futures like that one it's definitely an issue.
Assuming we're not abusing the API by using futures this way, one way around it would be disabling sinks for refc until this gets fixed.
The text was updated successfully, but these errors were encountered:
I've recently bumped into an issue that affects how
sink
parameters behave in refc and which can have adverse effects on Chronos' (V4) futures:sink
parameters can end up being passed by reference even when they should have been copied; i.e., even when there are later accesses to the same location at the caller.This can in turn cause surprising behavior as the
move
inchronosMoveSink
resets the location of the parameter, causing unexpected results:this prints "42, 0" when it should print "42, 42". If
AnObject
held a ref object ininner
, you'd crash with a SIGSEV.For async procs this seems to be less of an issue as capturing the parameter in a closure seems to get it copied somehow (I still don't get the whole mechanics), plus
complete
would typically only get called after user code is done so even accidental mutation is not the end of the world. But for code using "naked" futures like that one it's definitely an issue.Assuming we're not abusing the API by using futures this way, one way around it would be disabling sinks for refc until this gets fixed.
The text was updated successfully, but these errors were encountered: