ImageIO is thread-safe after all

In ImageIO is not thread-safe I reported a problem with ImageIO and threading. I now believe my analysis was wrong, and ImageIO is thread-safe after all. Serializing my ImageIO loading had the effect of hiding the race condition in my own code, so the error became very rare. My apologies to anyone misled by the post, and to anyone at Apple who had to deal with my bug report.

ImageIO is not thread-safe

This post is wrong. See ImageIO is thread-safe after all for correction.

I can't find any documentation one way or another, and assumed that as a modern API it was OK to call ImageIO from multiple background threads. It appears that this is not the case. CGCreateImageSourceFromURL fails randomly if you do; always calling it from the main thread appears to work.

Radar 5759067 requests that this preferably be fixed, or if not, at least documented.

A Delicious Limerick

How does he create all that buzz?
Wil Shipley says "Easy, it's 'cuz
    "for Delicious Lib'ry,
    "I've the weight of Mike Lee!
"Who says size doesn't matter?  It does!"

With apologies to Mike (and Wil), and thanks to limerickdb

Multithreaded libcurl Crash

Thread 0 Crashed:
0   libcurl.4.dylib                0x00391e1c curl_unescape + 78
1   libcurl.4.dylib                0x003929c0 curl_unescape + 3058
2   libcurl.4.dylib                0x00393978 curl_mvsnprintf + 55
3   libcurl.4.dylib                0x003850f9 Curl_failf + 63
4   libcurl.4.dylib                0x0037d8da Curl_resolv + 95

Apparently CURLOPT_NOSIGNAL is very important in multithreaded programs...

Leopard doesn't verify code signatures?

With all the fuss about code signatures in Leopard, I expected that the system would verify signed applications when they're launched, and prompt the user if the signature is incorrect. It doesn't.

To test this, first verify that TextEdit's signature is valid:

codesign -v /Applications/TextEdit.app/

(It should print nothing). Then edit /Applications/TextEdit.app/Contents/Info.plist. Make sure the edit is simple enough that you can undo it — changing the version number is an easy option. Now verify the signature again:

codesign -v /Applications/TextEdit.app/
/Applications/TextEdit.app/: code or signature modified

Now open TextEdit. It opens without warning. We could have replaced the executable with malicious code, and we wouldn't have been warned.

Make sure you revert your change to Info.plist and re-verify the application.

Since Tiger doesn't have any safeguards of this kind, obviously the situation is no worse than Tiger, but I don't understand what the point of code signing is if the OS doesn't make use of it to make the user's experience that little bit safer.