diff options
| author | fusion32 <marcopuzziello@gmail.com> | 2025-06-19 03:13:48 -0300 |
|---|---|---|
| committer | fusion32 <marcopuzziello@gmail.com> | 2025-06-19 03:13:48 -0300 |
| commit | bd3a6a04601749cbde007eaabf803fb602ee2783 (patch) | |
| tree | 476b89932627aa73ad88de22d37e4617bbdb1795 /TODO.md | |
| parent | e5b8aadd493b8b5df4ed661f2491de33d634b001 (diff) | |
| download | game-bd3a6a04601749cbde007eaabf803fb602ee2783.tar.gz game-bd3a6a04601749cbde007eaabf803fb602ee2783.zip | |
beginning of `communication.cc`
Diffstat (limited to 'TODO.md')
| -rw-r--r-- | TODO.md | 3 |
1 files changed, 2 insertions, 1 deletions
@@ -20,7 +20,8 @@ I didn't dive into how exceptions are handled, but it seems that the ones relate ## Synchronization I'm not sure whether synchronization is done properly. The implementation of the first few `crplayer.cc` functions left me with a taste of race conditions although integer loads on x86 are generally atomic. -I'm also under the impression that `getpid()` is used for retrieving the current thread id, so we'll have to wait and see how things unfold outside the main thread. +## Threading +After some initial dive into `communication.cc`, it has become clear that the original codebase relied on `LinuxThreads` which, among its quirks, assigns different PIDs to different threads, explaining the usage of `getpid()`. It also seems it could lack automatically managed thread stacks which explains `CommunicationThreadStacks`. ## Estimate The decompiled file has ~115K lines of C. If we take ~15K lines to be rubbish, this can be round to ~100K. Considering a low estimate of 200 lines per day, the whole process could take up to 500 days which is quite a bit but not impossible. Now considering a high estimate of 1K lines per day, it could take 100 days which is also quite a bit. |
