I was an intern at SGI in the summer of 1998, when we shipped the latest minor version of IRIX, 6.5. I worked on a test suite for IRIX's pthreads implementation, and got to ship a teeny, tiny bit of real code that fixed a real-time hold-off in pthread_mutex_t. (IRIX is a hard RTOS, you see.) As things happened, the dot-dot releases of that minor version would be the last releases of IRIX to roll off the software assembly lines before SGI put it in maintenance mode for these last darn-near-30-years.
In 2000, I was the 20th-or-so full-time engineer at VMware, where I worked for 9 years. Then was at Facebook from 2009 to 2016, where I worked on the search backend (now replaced), HHVM (which still runs the Big Blue Application, a shrinking portion of the Meta Empire), and started FAIR in 2015 (which finally seems to have turned around the "open" sign with Yann's departure).
In 2016 I started at Slack as Chief Architect, where I mostly did not write a ton of code. I worked on a job queue scheduler which I would not be surprised to find has been replaced. And after that I was mostly encouraging/advising people doing Real Work.
All of which is to say, it is quite possible that the last code I've worked on professionally that is out there running on customer machines ... is that libpthread mutex bug fix from when I was barely old enough to drink.
It's an easter egg on the website that usually goes unnoticed. It's our first time on the front page of HN, so it's a little overutilized right now. Capital-C clears it.
Hi Fil! Congrats on all the amazing progress on Fil-C.
We needed to port all the user-level fork(2) calls to vfork(2) when working on uCLinux, a port of Linux to MMU-less microcontrollers[1]. It used to be that paging MMUs were kinda expensive (those TLBs! so much associativity!!!), and the CPU on your printer/ethernet card/etc. might not have that much grit. Nowadays not so much.
Still. A hard-and-fast use for vfork(2), as requested perhaps.