Why I got a Datarace error?

[yunfengzh]

The script is briefly below:

let relic = #{
    on_player_die: |evt, cnt| {
            ...
            player.set(3); // crashed with datarace error!!
            ...

};

fn fight() {
    player.adjust(-15);
    1
}

================
player var is a rust var registered into script. Player will broadcast an event into script by relic.on_player_die().

I just want to know why rhai prevents above code pattern at all? If it‘s for infinite recursion, Engine.set_max_call_levels(16) is enough!

[schungx]

A panic in the Rhai engine is always a bug, so something is wrong if you get it to crash.

There are a few known patterns but they tend to be very rare.

When you say "crashed" do you mean the script terminates with a "data race" error?

Or do you mean a panic?

[yunfengzh]

I means above call-chain is normal script flow
script function >> rust function >> event is trigged, then return to script function, etc.
Of course, it maybe incur infinite recursion, but it's the responsibility of game developer and MOD developer to solve it, currently, rhai simply blocks the call chain by datarace error which makes a lots of jobs can't continue! Can you remove datarace error?

By the way, in Cargo.toml
rhai = { version = "1.25", features = ["default", "sync", "serde"] }
when open sync feature, what is done in underlying rhai? My context is player.on_player_die event is subscribed by multiple scripts, so I need sync multiple threads to Scope::*_var. So I need to know what rhai has done?

[schungx]

Let me understand you more fully. Please elaborate if I misunderstand.

You have a script: when run, it triggers another scripted function.

This is like a "cascading update" (or waterfall update), which you probably term "infinite recursion". In fact, it doesn't seem to be recursion, just cascading event triggers.

In those functions, your scripts are defined based on closures, and they capture (it seems to me) the player object.

The same player object that was used in the original calling, triggering script.

So, this is a text-book data-race. Cascading updates are ripe sources of data races, and Rust is designed to specifically stop you from harming yourself like this. Rhai will also catch most of these incidents.

You can avoid the data-race in cascading updates by implementing an event queue. However, there may be issues if you're depending on the result of an event trigger to move on... in which case it would be strange as those will no longer be event triggers but functions. In the vast majority of cases, you can use an event queue successfully with no data races.

[yunfengzh]

I think the problem is just about who should be the target user of rhai. In my option, rhai target user is program beginer, that is why I choose it as a MOD script because you can't assume MOD developer is good at program just like rust developer. So rhai must be a simple language, so it can't include such as lifetime, reference, memory management, async, etc. However according to above discussion, rhai tries to prevent a dynamic object is mutate-accessed several times which is advantage feature of rust, the feature is totally unnecessary to rhai. So what your advice about rhai?

[schungx]

So what your advice about rhai?

I suggest you modify your API such that it does not cause data races.

I disagree with you that it is OK for casual programmers to cause data races. Data races are VERY hard to reason about and the bugs are usually very subtle and hard to reproduce. A casual programmers, I'd assume, has no chance to debug a data race issue.

My view is that you should avoid it as much as possible. That's why cascading updates are so hard to reason about because they are order-dependent and the result sometimes depend on chance. I'd suggest you change your MOD system to avoid cascading updates.

Look at cascading update features in databases and how many subtle keywords they need just to specify it. Also look at the JsvaScript mess and you can see how out-of-control eventing can cause havoc.

But even JavaScript is not cascading updates. The eventing system is single threaded working off an event queue. Think what a huge mess it'd be if JavaScript activates events in place like you propose to do.

[schungx]

I'm wondering if you have resolved your issue?

[yunfengzh]

No, my rust->rhai event model not only need cascading-update the same object, but also need return value of every event-callback. Even the solution is exist, script developer also need multiple APIs to achieve a simple logic, it's too hard to them.

So I just wonder what happen if I comment all Dynamic::Union::Shared instance construct?

[schungx]

No, my rust->rhai event model not only need cascading-update the same object, but also need return value of every event-callback.

I'd then seriously advise you to rethink your API. Unless you have exactly one handler to each event, you'd have prob deciding which value to return and from which handler. Ordering would be a nightmare and you cannot parallel run them.

[yunfengzh]

I plan to run a thread for all scripts, so there's no parallel problem at all. And my problem is rust need broadcast event to script and maybe script can return a value to block the event is dispatched to later subscripters. I also hope there is no complex API for MOD developer because too complex API maybe refuse them finally. That is why I ask you what you do when feature sync is set in Cargo.toml? Any advices.

[schungx]

Sort of like JavaScript's preventDefault() and others such as stop bubbling of event?

In that case you may want to, like JavaScript, have an event object that can be modified to return these info instead of returning a value (which is very limiting and would definitely cause race conditions).

I honestly feel that you need to think it through. You have not considered the actual runtime complexity. You will get bitten.

I wrote too much event driven code in my lifetime to tell you this.

[yunfengzh]

You solution is also not perfect!
let relic = #{
on_player_die: |evt, cnt| {
...
let armor = player.get_armor(); // crashed with datarace error!! <<<<<<<<<<<<<<<<<<
player.set(3); // crashed with datarace error!!
...
};

Script can become very complex, if reilc need to detect whether player has an armor, if not rescue it, otherwise do nothing, what is your solution?

[schungx]

Is player a captured external variable?

Can you do something like:

let relic = #{
on_player_die: |evt, cnt| {
...
let armor = this.get_armor();
this.set(3);
...
};

So during on_player_die map the player variable into this of the closure.

The trick is to have only one object that you map to this... If you need multiple objects assessed, you can create a map with properties then map the map to this.

Of you can use something like https://rhai.rs/book/patterns/global-mutable-state.html

[yunfengzh]

Script player var comes from rust
#[derive(Clone)]
struct PlayerProxy {
p: *mut Player, // of course, I can change it to Arc if need
....
}

Let us clarify the problem, script is written by MOD developer, so I know nothing about what is in it, the only thing I know is trait definition.
trait Life {
fn on_player_die(&self, evt: Hurt, unused: i64) -> Revive;
}
But I need a unique solution to prevent script trigger Datarace error, above sample is ONLY sample.

I think the simplest solution to remove Datarace just I have said, can you add a feature in Cargo.toml -- nodatarace, when it is on, skip all Dynamic::Union::Shared construction.

[schungx]

I think the simplest solution to remove Datarace just I have said, can you add a feature in Cargo.toml -- nodatarace, when it is on, skip all Dynamic::Union::Shared construction.

No, that won't be possible, as we're using Rust here. Rust itself would not let us cause a datarace. The error is not a Rhai error... it is Rust error.

Of course I can throw in a massive amount of unsafe just to comment out all the Rust safety checks, but I don't think we'd do that here.