npth finds pthread_mutex_timedlock() which android does not have

[Marcus Brinkmann]

On 02/28/2012 06:44 PM, Hans-Christoph Steiner wrote:
>
> On 02/28/2012 11:32 AM, Marcus Brinkmann wrote:
>> On 02/20/2012 11:16 PM, Hans-Christoph Steiner wrote:
>>
>>> Turns out there is another issue with npth on Android.  npth_yield is a
>>> macro for pthread_yield, which Android does not seem to have.  I cannot
>>> find another confirmation of this besides pthread_yield() not being any
>>> headers.
>>
>> While I find the disregard for standard compliance in Android deeply
>> disturbing, in this case the right fix is to remove npth_yield entirely
>> (which should have been a function anyway, as it needs to release the
>> global lock temporarily).  yield is considered harmful, and I changed
>> the only place where it is called in gnupg with a sleep (well, there are
>> some more calls in the windows CE port which will eventually be taken
>> care of).
>>
>> npth: c30634abebb287f56a6a2480b4bbd2ffc166dd4d
>> gnupg: 8f8c6594147608b1021c16fc3561feb96da5d55a
>
> That's great, I'll try a build right now.  I also noticed that you
> committing some changes to make pthread_rwlock* optional.  Do you think
> that will ultimately apply to dirmngr as well?

Yeah, but it's not a complete fix yet.  The ultimate situation will be 
to use a simple mutex if rwlocks are not present at all.  rwlocks are 
really just an optimization, and should degrade fine to a standard mutex 
(the windows port used to do that).

> As for Android's standard compliant, it is a bummer.  I find it useful
> to understand their view on the native side of things when thinking
> about this stuff.  First off, Android isn't UNIX, its a new thing with a
> Linux kernel and some UNIXish stuff (for example, most stuff is in
> /system).  Then, the original intention is that developers would only
> ever work in Java, and they do provide a complete and
> standards-compliant Java SDK.  It is only because of large developer
> demand have they been convinced to open up the underlying C layers for
> general development, so now are starting to catch up with standard
> compliance there.

That sounds like a good explanation of what's going on, thank you.

Marcus