add fork support, like linux kernel, every process has one freebsd struct thread#887
Merged
jfb8856606 merged 1 commit intoMay 23, 2025
Conversation
Closed
jfb8856606
added a commit
that referenced
this pull request
May 26, 2026
…since v1.22
Reorganize adapter/syscall/README.md (mirrored from the LD_PRELOAD
documentation) to reflect the state of libff_syscall.so as of 2026-05-25.
Removes 'Beta / only for testing' wording from the title and intro while
keeping a 'Known Limitations' section for the structural items that are
still open (e.g. cannot act as a client across multiple fstack instances,
sendmsg/readv/recvmsg paths not yet performance-tuned).
Adds a 'Feature Updates Since v1.22 (2023-05-04 ~ 2026-05-25)' section
that summarizes the major work landed in adapter/syscall/ since v1.22:
New Features
- Lock-free rte_ring IPC (FF_USE_RING_IPC) replacing the sem-based
shared memory path; v3.4 ring optimizations (D2/D5/D6) are now the
default behavior of the ring branch.
- epoll polling mode for RTT-sensitive workloads.
- fork support: every forked process owns its own FreeBSD
struct thread (PR #887).
- accept4 with LINUX_SOCK_CLOEXEC / LINUX_SOCK_NONBLOCK.
- glibc _FORTIFY_SOURCE wrappers: __recv_chk / __read_chk /
__recvfrom_chk.
Improvements & Bug Fixes
- FF_KERNEL_EVENT epoll kernel fd leak fix in ff_hook_close.
- cplen calculation fix in ff_hook_syscall.c.
- ff_hook_recvfrom sh_fromlen uninitialized fix (PR #872).
- ioctl conflicting types compile error fix (PR #942).
- ring IPC startup-time starvation fix under FF_MULTI_SC +
idle_sleep = 0.
- Ubuntu 22.04 / kernel 5.19 / gcc 11.4 build fixes (#777).
Adds an FF_USE_RING_IPC appendix entry and an Acknowledgements section
that thanks the two main external contributors over this window:
liujinhui-job and zhaozihanzzh.
Line endings normalized to LF.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current fork implementation has an issue: after creating a socket and invoking fork, both the parent and child processes call close. When the parent process closes the socket, it is released immediately. Subsequently, when the child process attempts to close it, the file descriptor (fd) no longer exists. This behavior differs significantly from Linux, which can lead to various problems. In a true Linux implementation:
Child processes inherit open file descriptors from the parent upon fork, meaning the reference count of the file is incremented.
Each process in Linux corresponds to a task_struct.
The purpose of this commit is to simulate Linux's behavior by addressing these two aspects.
The partial reason has been explained in my CSDN blog：
https://blog.csdn.net/weixin_41607301/article/details/146396412?spm=1001.2014.3001.5502