RE: Why isn't pthread_rwlock_rdlock() deadlocking???
RE: Why isn't pthread_rwlock_rdlock() deadlocking???
- Subject: RE: Why isn't pthread_rwlock_rdlock() deadlocking???
- From: "Karan, Cem (Civ, ARL/CISD)" <email@hidden>
- Date: Mon, 1 Jun 2009 08:06:29 -0400
- 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden