Noting that process scheduling in ckb-vm is deterministic

[mohanson]

The developer may suspect that there will be randomness in the implementation of spawn, so this sentence is added intentionally.

[mohanson]

cc @xxuejie @XuJiandong

[xxuejie]

I recommmend expanding this section a bit:

• For each hardfork version, the process scheduling will be deterministic, any indeterminism will be treated as critical / security bugs that requires immediate intervention
• However, based on real usage on chain, it is expected that future hardfork versions would improve the process scheduling workflow, hence making the behavior different across versions

Simply put, the scheduler included in CKB will be deterministic with respect to a particular hardfork version, and will likely change its behavior in different hardfork versions.

[XuJiandong]

Provide detailed information about the deterministic scheduler, including:

1. The criteria for selecting the next process to run when one process is blocked.
2. The conditions under which deadlock can occur.
3. The specific operations that can cause a process to become blocked.

[xxuejie]

Provide detailed information about the deterministic scheduler, including:

1. The criteria for selecting the next process to run when one process is blocked.
2. The conditions under which deadlock can occur.
3. The specific operations that can cause a process to become blocked.

I'm not entirely sure here: are those information suitable for RFC, or separate documentations?

An analogy here, could be the details of the transaction pool, those are also highly tied to actual implementation, yet the RFCs does not fully describe those.

FYI: I'm not against adding those information, they certainly help, but it is worth discussing where they should fit.

[mohanson]

I suggest putting the detailed working principle of the scheduler in a separate document.

[xxuejie]

A second thought: I think it makes sense to document the deadlock conditions for each hardfork versions here; but other details fit better in a separate document on Nervos docs.

[mohanson]

A second thought: I think it makes sense to document the deadlock conditions for each hardfork versions here; but other details fit better in a separate document on Nervos docs.

There is already descriptions of when read/write/wait will cause deadlock

https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0050-vm-syscalls-3/0050-vm-syscalls-3.md#write
https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0050-vm-syscalls-3/0050-vm-syscalls-3.md#error-code

[xxuejie]

Yes but the words are quite vague:

If ckb-vm detects that all processes are blocked, ckb-vm will return a deadlock error.
It's possible for read/write/wait operations to wait for each other, leading to a deadlock state.

I think it makes sense to specifically define when all process will be blocked, and what it means for operations to wait for each other.

[mohanson]

I added a separate section to describe deadlocks, please check @xxuejie @XuJiandong