Recursive locks? Locking API?

[Freddie Chopin <freddie_chopin at op dot pl>]

Hi!

Does newlib REALLY need recursive locks? Couldn't some parts of it be 
rewritten to use normal - binary - locks only?

The other thing is the API used for locking - I've read somewhere that 
ultimately you'd like to use only sys/lock.h API for malloc()/free() and 
for env too, but actually for embedded targets overriding current 
__malloc_lock() and __malloc_unlock() is trivial, while using API from 
sys/lock.h requires configuration and recompilation of whole toolchain 
(by default all of lock functions are "(void)0") - maybe some default 
and overridable stubs (like for malloc/env) would be a better solution? 
For ARM embedded targets at least...

I'm talking about using newlib with tiny embedded RTOSes like 
ChibiOS/RT, FreeRTOS etc. - these are not typical "systems", so it makes 
no sense to have a port of newlib for them, but it would be nice to 
easily use locking in your app. Some of these systems don't provide 
recursive mutexes, so recursive locking is a problem...

4\/3!!