#any way to ensure awaiting on actor is deadlock-free

7 messages · Page 1 of 1 (latest)

chrome stream
#

I'd recommend writing a simple version of your code (e.g. a small cli project) that only has the minimal parts of this that matter to the question. Removing the excess cruft can make it easier for people to be on the same page as you about the design choices you've made. Start with the simple version of this to show the issue, without trying to solve the problem by adding tasks etc.

To force the deadlock to occur deterministically, add sleeps at the points where you expect things to happen before / after and write the calling code so that those time waits make sense . I.e., put a 2 second wait in between the call and waiting for the response, but make the second call 1 second after the first to ensure that it happens in that gap.

solemn charm
#

This might be your idea already, but for this I would ensure that your player actor doesn’t have access to that PLAYERS object, or doesn’t have access to the ask method.

Instead, the player actor has a way to spawn a task that does have access to ask another player something. This sort of information hiding will ensure that you can’t do the wrong thing.

Of course, it looks like your PLAYERS object is some global static, so you may want to wrap that up in some other object (maybe also a global static), such that you need a specific owned handle to work with it. Passing an Arc around instead of using a static can work here.

brittle ice
#

at some point we should see equivalent functionality make its way into the runtime as well (there's been some discussion about it)

weak slate
#

#1280620542990356481 message

brittle ice