|
Boost : |
From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-03-25 17:43:53
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 :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk