Closed mohanson closed 3 months ago
There is trivial difference for TPS in benchmark testing
benchmark data for this PR
duration send tx tps 615,duration avg delay 12.958ms,sum tps:607
benchmark data for yukang-new-verify
branch
duration send tx tps 584,duration avg delay 13.656ms,sum tps:608
cc @gpBlockchain, you may want to double confirm it and also run benchmark testing for transactions with large cycles.
The design of the syscall spawn
function draws inspiration from Unix and
Linux, hence they share the same terminologies: process, pipe, and file
descriptor.
In the context of ckb-vm
, a process represents the active execution of a
RISC-V binary. This binary can be located within a cell, which is indicated by a
script or OutPoint
. Additionally, a RISC-V binary can also be found within the
witness during a syscall spawn
operation. A pipe is established by associating
two file descriptors, each linked to one of its ends. These file descriptors
cannot be duplicated and are exclusively owned by the process. Furthermore, the
file descriptors can only be either read from or written to; they cannot be both
read from and written to simultaneously.
When the spawn serial syscalls (such as ckb_spawn, ckb_read, ckb_write, etc.) are invoked, the corresponding process will yield, and they will be scheduled to run again. Some processes can run immediately, while others will enter a "wait" status (VmState::Wait, VmState::WaitForWrite, VmState::WaitForRead) due to IO operations.
During the wait status, there are two forms of memory representation. The first is the "instantiated" status, which holds the full memory of the process. The second is the "suspended" status, which holds a snapshot of memory. The latter can save a significant amount of memory. When the process is ready to run, a process with "suspended" status becomes "instantiated" by unpacking the snapshot into full memory.
The spawn introduces the following syscalls:
Some usage of syscalls can be found here.
See Draft RFC documentation for more information.
Please find the attached coverage report from unit tests: tarpaulin-report-0417.html.gz
It is generated via cargo tarpaulin:
cargo tarpaulin -o html --tests -- v2023
In this PR, we refactored the implementation of spawn. The refactored syscall API is defined as follows: https://github.com/XuJiandong/ckb-c-stdlib/blob/syscall-spawn/ckb_syscall_apis.h#L54-L68.
Review Introduction: https://github.com/nervosnetwork/ckb/pull/4380#issuecomment-2058070291
Documentation: https://github.com/nervosnetwork/rfcs/pull/436