[cfe-dev] [libcxx] A few questions about external threading support

[Liu Hao via cfe-dev]

On 2017/3/30 12:45, Eric Fiselier wrote:
> There is one version that I know of, but the expectation of external
> threading implementations is that they track trunk very closely. There
> is absolutely no guarantee of API compatibility in the external
> threading interface. It's not meant to be a stable interface.
But you can change its name so if a user picks a wrong dynamic library 
by accident he will get an undefined reference, instead of an obscure 
fault because the old function doesn't return a non-zero value upon 
success - just the opposite.

> Good point. Changing the try_lock() definition to use that may not be
> ABI breaking, but it may be a backwards incompatible change if other
> methods depend on certain invariants that try_lock() no longer maintains.
>
> I would rather apply your suggested fix and remove the condition
> variable entirely so that we get the reduced class size as well. We have
> mechanisms for staging/guarding ABI breaking changes, so we might as
> well use them.
Then there are going to be `__libcpp_mutex_timedwait()` and 
`__libcpp_recursive_mutex_timedwait()`, aren't there? Then would they 
return `bool` or `int`? The pthread equivalents return `int` anyway.

-- 
Best regards,
LH_Mouse