Peter Dimov wrote:
Yuval Ronen wrote:
Peter Dimov wrote:
Yuval Ronen wrote:
So to rephrase what I wanted to say in the most concise manner - the cost I was talking about is that the interoperability requirement makes N2184 impossible. As simple as that. I've no idea what you mean, sorry. What part of N2184 is impossible and why? It depends on what kind of interoperability we're talking about. If we want to manipulate in C++ mutexes created in C or vice versa, then the example from the previous post explains it.
There are no mutexes in N2184.
True, but N2184 is based on N2094 which does. Doesn't matter; the thread stuff is more interesting.
If we want to manipulate in C++ threads created in C or vice versa, then we have pthread_t exposition problems which are the basically same problems as described for mutexes,
N2184 does expose a pthread_t under POSIX, see 'native_thread_handle'.
Right. This goes under "how to manipulate in C, a thread created in C++", which is what I claimed to be a minor thing. The major problem is the other way around - how to manipulate in C++, a thread created in C.
and in addition, we also have the join/cancel problems which were described elaborately by Howard.
An interoperability requirement for pthread_cancel doesn't make N2184 impossible, just infinitely more useful.
In this area I know much less than you guys, but I have to say I find it very hard to imagine how such interoperability would look like. If I'm wrong and it really is possible, then that's good news for me :-)