intertent.net 3.0

Amongst many others, OS X has the following synchronization primitives:

• Named POSIX semaphores
• pthread condition variables
• Mach Semaphores

Unnamed POSIX Semaphores (sem_init()) are not supported (the function is defined in the header but calling it returns ENOSYS).

Named POSIX semaphores and condition variables are implemented internally using Mach semaphores which in their own right are virtually undocumented apart from a few functions which you can find manpages for in the XNU source code under osfmk/man.

The relevant functions are defined in mach/semaphore.h.

The implementations of pthread condition variables and POSIX semaphores are publicly visible as part of the open source XNU code and are pretty clean, it’s really nice to see how those are implemented behind the scenes.

One more tidbit is that if a thread is waiting on a Mach semaphore, then sending a signal to that thread via pthread_kill() will cause semaphore_wait() to exit (with an error code). I’m not sure if the semaphore will remain in a consistent state in this case, I’m merely mentioning that for future reference.

Mach semaphores are counting semaphores, unlike named POSIX semaphores they are reference counted and will go away if your process dies (rather than being allocated in a kernel table and staying around indefinitely). AFAIK Apple considers Mach semaphores an SPI [private] and therefore either the API or it’s internal behavior may change between arbitrary system releases so caveat emptor.

I was playing around with crontabs and duplicity today on OS X 10.5 Leopard. I’d written a python script that executes duplicity, my script ran just fine from the shell, but churned out the following cryptic error message when run from crontab:

...
Cleanup of temporary directory /var/folders/7Q/7Qlu3ZqFHeuxCbNgaimO2E+++TI/-Tmp-/duplicity-ben2Y6-tempdir 
failed - this is probably a bug.
Traceback (most recent call last):
 File "/opt/local/bin/duplicity", line 553, in <module>
   with_tempdir(main)
 File "/opt/local/bin/duplicity", line 547, in with_tempdir
   fn()
 File "/opt/local/bin/duplicity", line 528, in main
   full_backup(col_stats)
 File "/opt/local/bin/duplicity", line 225, in full_backup
   sig_outfp = get_sig_fileobj("full-sig")
 File "/opt/local/bin/duplicity", line 203, in get_sig_fileobj
   fh = globals.backend.get_fileobj_write(sig_filename)
 File "/opt/local/lib/python2.5/site-packages/duplicity/backend.py", line 341, in get_fileobj_write
   fh = dup_temp.FileobjHooked(tdp.filtered_open("wb"))
 File "/opt/local/lib/python2.5/site-packages/duplicity/path.py", line 644, in filtered_open
   elif mode == "wb": return gpg.GPGFile(1, self, gpg_profile)
 File "/opt/local/lib/python2.5/site-packages/duplicity/gpg.py", line 105, in __init__
   'logger': self.logger_fp})
 File "/opt/local/lib/python2.5/site-packages/GnuPGInterface.py", line 357, in run
   create_fhs, attach_fhs)
 File "/opt/local/lib/python2.5/site-packages/GnuPGInterface.py", line 401, in _attach_fork_exec
   if process.pid == 0: self._as_child(process, gnupg_commands, args)
 File "/opt/local/lib/python2.5/site-packages/GnuPGInterface.py", line 442, in _as_child
   os.execvp( command[0], command )
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/os.py", line 353, in execvp
   _execvpe(file, args)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/os.py", line 389, in _execvpe
   func(fullname, *argrest)
OSError: [Errno 2] No such file or directory
...

It turned out the underlying problem was that gnupg was installed via Mac Ports which installs into a directory that’s not in PATH by default. Adding /opt/local/bin to PATH got things working.

The “Cleanup of temporary directory bla failed - this is probably a bug” message is kind of misleading…

Yesterday I ordered tickets on Fandango, at the end of the process I was rewarded with a familiar popup window at the bottom of the browser.

Turns out, Fandango are nice enough to automagically add a post to your Facebook minifeed when you order movie tickets through them.

The sad part is that this is turned on by default and it’s not immediately obvious that this is happening (why should Fandango & Facebook be linked??).

I’m sure this is terrific publicity for Fandango, but sucks in terms of privacy. Features like this should always be opt-in.

Seems that I’m not the only one who’s troubled by this.

While it may seem like good business sense to not ask the user and increase revenue from advertisers in the short term, I think companies have to really be careful harming their brand with things like this. Personally I think you can only get privacy and security right if they’re designed into the product on day one.

Google just released an open source C++ style guide, lots of good solid advice in there.