diff options
Diffstat (limited to '')
| -rw-r--r-- | results/scraper/fex/168 | 5 | ||||
| -rw-r--r-- | results/scraper/fex/1680 | 2 | ||||
| -rw-r--r-- | results/scraper/fex/1681 | 8 | ||||
| -rw-r--r-- | results/scraper/fex/1687 | 12 |
4 files changed, 27 insertions, 0 deletions
diff --git a/results/scraper/fex/168 b/results/scraper/fex/168 new file mode 100644 index 000000000..7b1e2fdf8 --- /dev/null +++ b/results/scraper/fex/168 @@ -0,0 +1,5 @@ +Resolve paths passed to VFS/HLE to canonical +Find all VFS HLE routines, such as +EmulatedFDManager::OpenAt() and resolve path arguments to canonical form before using in map<path,fd> + +Currently only absolute paths that match perfectly will work. \ No newline at end of file diff --git a/results/scraper/fex/1680 b/results/scraper/fex/1680 new file mode 100644 index 000000000..59c95d83a --- /dev/null +++ b/results/scraper/fex/1680 @@ -0,0 +1,2 @@ +Implement VMA merging for our memtrack code +Follow up from #1558, after new maps, or permission changes VMAs might be mergeable. \ No newline at end of file diff --git a/results/scraper/fex/1681 b/results/scraper/fex/1681 new file mode 100644 index 000000000..8fd62462a --- /dev/null +++ b/results/scraper/fex/1681 @@ -0,0 +1,8 @@ +std::shared_mutexes can't be safelly locked across forks +I run into this as part of #1558. + +If they are locked before fork, then after fork they may or may not lockup on next lock, semi-randomly. + +Looks like we need to roll our own `shared_mutex` implementation. + +In general in need a gameplan for fork safety of FEXCore / Syscalls code \ No newline at end of file diff --git a/results/scraper/fex/1687 b/results/scraper/fex/1687 new file mode 100644 index 000000000..cba9917de --- /dev/null +++ b/results/scraper/fex/1687 @@ -0,0 +1,12 @@ +shared_mutex with unique lock priority +Having a shared lock where unique locks take priority would be beneficial. +std::shared_mutex gives shared locks priority when a shared lock is already held. + +With a new lock with unique priority it should have the properties: + +1. When a shared lock is already held and then a unique lock is attempting to be made + - Subsequent `try_lock_shared` should immediately return false even though unique_lock isn't held yet + - Subsequent `lock_shared` should block until unique lock is granted and relinquished + - If a subsequent unique lock is pending while a unique lock is already held then a shared lock shouldn't be able to win the contention. + +Might be worth using `WFE/WFET` for faster userspace checking of lock if it is expected to not be contended for too long. \ No newline at end of file |