> Anyways, I’ve been learning some interesting things about OSX that I’ll be sharing soon.
Nice, that should be amusing to read. OSX is a very strange system -- it has two system call APIs (BSD, and Mach), which respectively have some very odd holes. Some of the OSX syscalls return values split between 32 bit registers instead of in a single 64 bit register, while others don't. Some of them return things by value, even though the C API specifies out parameters. And so on.
I've spent way too much time trying to figure out how this stuff works on OSX when writing Myrddin (https://github.com/oridb/mc). I've still got quite a bit more to do so that I can finish implementing libthread on OSX.
What I've been wondering, is any of this documented? I'm kind of sick of reading old headers, that were published years ago.
Anyways, your language looks cool!
I've got to get threads working, so maybe I'll have some info that can help, but I doubt it. I simply need to create and exit them, not implement all of pthreads.
There's some out there, but not much. I haven't been able to find any for things like bsdthread_create, other than reading the open source code that Apple put out for libpthread.
Thankfully, that code was available -- without it, I would have had no idea that the 'stack' parameter for bsdthread_create would act as the stack size, instead of as the a pointer to the top (or bottom) of the stack.
Although, that being said, I'm currently still stuck on getting it working. The test for spawning threads is fine when I run it under 'sudo dtruss test/spawn', but as soon as it's not under dtruss, it fails to spawn the thread.
EDIT: when I say "some", I should probably post a link.
> The test for spawning threads is fine when I run it under 'sudo dtruss test/spawn', but as soon as it's not under dtruss, it fails to spawn the thread.
Ah, the fated Heisenbug.
I skipped over all of the calls in my dtruss example in this post, but I recall dtruss listing itself making a few syscalls. I wonder if a missing signal handler is to blame?
Also, thanks for pointing out Apple's pthread implementation! Great idea!
Yes, I've also seen those issues with dtruss -- it seems to work better when you run it separately in another terminal:
sudo dtruss -n myprocname
It doesn't seem to trace itself, and now your program can run as a regular user. And in my case, it even catches the failure for bsdthread_create, although it drops some of the arguments, and the ones it does show seem identical enough. (And no, it's not the sudo that's making it work.)
I've got back into low level debugging on Windows for mixed x86 & C++ code recently. Here's my summary of useful resources: https://etrading.wordpress.com/windbg/
What is this, a site for ants?! ctrl-0 ctrl-0 ctrl-0
I jest, but great resources. I'm always impressed with debugging tools from Microsoft. The past couple of GDCs [0] I've spent lots of time in their booth fawning over the beautiful graphics debuggers. Sometimes, I wonder why we can't have nice things............OpenGL....all I wanted for Christmas was Vulkan....
Nice, that should be amusing to read. OSX is a very strange system -- it has two system call APIs (BSD, and Mach), which respectively have some very odd holes. Some of the OSX syscalls return values split between 32 bit registers instead of in a single 64 bit register, while others don't. Some of them return things by value, even though the C API specifies out parameters. And so on.
I've spent way too much time trying to figure out how this stuff works on OSX when writing Myrddin (https://github.com/oridb/mc). I've still got quite a bit more to do so that I can finish implementing libthread on OSX.