RE: Why isn't pthread_rwlock_rdlock() deadlocking???
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: Acnf6n2ebEbZ2byaQxCUYkTBiNbIZwCxKs6w Thread-topic: Why isn't pthread_rwlock_rdlock() deadlocking??? Terry Lambert wrote on Thursday, May 28, 2009 7:06 PM: <<SNIP>>
The answer is that if you are targeting Leopard or later using supported development environments for Leopard or later, you're going to get the UNIX conformant behaviour by default, which will get you the checks you're wanting to get, and get you the error return.
Good, that is what I was after. My code is written to be highly paranoid; I ALWAYS check the return values of all calls, and I write unit tests for anything that I'm unsure of, which is how I found that pthread_rwlock_rdlock() wasn't doing what I thought it should be doing. What I want is all error checks that are available for all APIs. <<SNIP>>
The lack of checking is required for binary backward compatibility, to not change the behaviour of programs which have, for reasons of their own, written code which deadlocks, and, rather than eliminating the deadlocks, they've come up with some mechanism of their own for dealing with them (like alarm()'ing out of the blocking call), and effectively now depend on the deadlock behaviour.
...and that is why I'm not going to get what I hoped for in my comment above! Oh well... it'd be nice to have a compilation environment that was defined as 'every single check we can think of', and it was changed whenever necessary to add in more checks (no worries about backwards compatibility, as a developer, you should never ship anything with this environment, just develop with it) <<SNIP>>
Yeah, it's kind of annoying, if you are only coming to the UNIX table now, instead of years ago when the changes first went in, and are wanting to support OS releases from years ago without multiple binaries, but if you don't take the standards-compliant compilation environment, you don't get the protections and behavioural guarantees the environment offers you.
I like to think of it as additional incentives for making the switch to standards compliant code.
Fortunately for me, backwards compatibility is never an issue; we'll update to whatever is the latest, and all of our uses will get updated with us. And, yes, standards compliant code is what we aim for, it makes debugging simpler, and allows us to port between platforms more quickly. Thanks, Cem Karan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com
participants (1)
-
Karan, Cem (Civ, ARL/CISD)