Repository navigation
build(libkernel): compile Thread on macOS - #11246
iamthehimansh wants to merge 1 commit into
Conversation
Pthread/src/Thread.cpp reads the stack bounds with pthread_getattr_np and binds the thread CPU clock with pthread_getcpuclockid, neither of which macOS has. macOS now takes the stack bounds from pthread_get_stackaddr_np and pthread_get_stacksize_np, and reads the thread's user and system time with thread_info on its Mach thread port, which Pthread.hpp now stores in place of the clock id on macOS. Linux and Windows compile the same code as before.
MarcZX10
left a comment
MarcZX10
left a comment
There was a problem hiding this comment.
The macOS branches are consistent with the APIs used: the stack bounds come from the pthread stack address/size, and the cached pthread_mach_thread_np port is queried with THREAD_BASIC_INFO for user plus system CPU time. I did not find a concrete code defect. The checks on this head pass eligibility, conventions, intake, labels and report; product/build jobs are skipped, and the PR's local evidence is compile-only.
Because both changed behaviors are macOS-only, could someone with macOS run the existing guest-thread stack and CPU-clock tests (or add focused coverage if those tests do not exercise these branches) before merge? I have not run the runtime paths on macOS, so I am leaving this as a comment rather than approving on compile evidence alone.
|
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
|
Closing this in favour of @mugurc's #7804, as @MarcZX10 pointed out. #7804 is older, already reviewed, and carries the same macOS code for this file: stack bounds from I missed it because my overlap check only fetched the first 500 of the ~1,000 open PRs, so it never compared against #7804. That's fixed now. Sorry for the noise, and thanks for the review. AI-assisted: yes (Cana) |
What
Next part of splitting #8658:
libkernel'sPthread/src/Thread.cppdoes not compile on macOS. The change is macOS-only; Linux and Windows compile the same code as before.pthread_getattr_np. It takes the stack top frompthread_get_stackaddr_npand the size frompthread_get_stacksize_np.pthread_getcpuclockid. The thread's Mach port is stored when the thread starts, and its user plus system time is read withthread_info(THREAD_BASIC_INFO).Pthread.hppholds that port in place of theclockid_ton macOS.#11201 and #10856 also change
Thread.cpp, in other functions; neither touches these lines.Tested
macOS 26 on an Apple M2 Pro, x86_64 under Rosetta 2, Release with Ninja, on
mainatb90d009d9:Pthread/src/Thread.cpp.oandPthread/Posix/Thread.cpp.ocompile, wheremainfails the first. Thelibkerneltests cannot run on macOS until the rest oflibkernelbuilds (#11240 and follow-ups), so this is a compile check only. On #8658's branch the same code passedguest_thread_cpu_clock3 of 3 runs. For Linux and Windows, I checked each file's view underunifdef -U__APPLE__, with-D__linux__and with-D_WIN32: it equalsmain.python3 tools/check_conventions.py --base origin/mainpasses.Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file.mdfiles or images added to the repository (attach them to this PR)