Re: [ANNOUNCE]: LuaThreads 1.0-work, pre-release

[Diego Fernandes Nehab <diego@...>]

Hi,

> [mutex:lock()]
> If the caller thread is already the owner of the mutex, nothing happens. 
> [mutex:unlock()]
> If it owned by the caller thread, it is switched to the unlocked state. 

> - Does this imply that mutex locks do not correctly nest?  If so I think
> it would be extremely beneficial (and far less error prone) if they were
> made to do so.

Sorry about that. I made a confusion with this. The manual is wrong. The
way it is now, mutex:lock() on a  owned mutex will dead-lock on Unix and
nest on Win32.

I remember reading  that recursive mutexes (those that nest)  can not be
used  with  condition variables  in  some  pthread implementations,  and
that's why I chose  the fast (and default) ones. Also,  I think they are
not portable. I will check on that, but  I don't think it would be worth
it to implement them by hand for performance reasons.

In the Win32, I am using critical  sections because they are faster. And
they happen to nest... And so do Win32 mutexes.

I will think about the direction to  follow, but I don't think relocking
a mutex is  good practice. Meanwhile, I will correct  the manual, saying
the behavior is unspecified.

Regards,
Diego.