Thanks for your answer!

And I suggest adding a line in boost.thread document to say something like:

"it's safe to mix usage of boost.thread and native thread api in cases: blah blah..."

so others won't be hesitant to change using boost.thread with existing frameworks or in legacy systems.

On Mon, Feb 1, 2010 at 3:11 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

----- Original Message -----
From: "OvermindDL1" <overminddl1@gmail.com>
To: <boost-users@lists.boost.org>
Sent: Saturday, January 30, 2010 8:23 AM
Subject: Re: [Boost-users] mix usage of boost.thread and pthread?


> On Fri, Jan 29, 2010 at 11:22 PM, Hua Su <huas.su@gmail.com> wrote:
>>
>> On Sat, Jan 30, 2010 at 7:37 AM, Anthony Williams <anthony.ajw@gmail.com>
>> wrote:
>>>
>>> Hua Su <huas.su@gmail.com> writes:
>>>
>>> > Is it OK to use both pthread and boost.thread in the same program under
>>> > linux?
>>>
>>> Yes.
>>>
>>> > 1. use pthread api to create/join/detach/cancel threads but use
>>> > boost.thread's
>>> > mutex/condition_variable etc. to do thread synchronization, and
>>> > this_thread/
>>> > sleep/get_id/thread_local_storage etc..
>>>
>>> That's fine.
>>
>> Another reply of this topic by OvermindDL1 said "things like this_thread
>> will not work on non Boost.Threads". Could you give any explanation about
>> this?
>
> I may be wrong, but I could have *sworn* that at one point in time if
> I used native windows threads, then some of the Boost.Threads
> functionality just kind of choked.  Am I wrong?  If so, I would love
> to know.  :)

Hi,

the functions at the this_thread namespace can be used in native threads without any know issue. You are not alone to think that and an example on the documentation should be added to show the possibility. This was a requirement as libraries don't know which kind of threads calls its functions.

In general all the combinations should work, as pointed by Anthony. The usage of Boost.Thread resources by other parts is available using the native_handle() API (note that not every resource has the native_handle() function). The oposite is not supported except by the current thread., i.e. if a part of the program gives the reference of a pthread resource, there is no mean to retrieve the Boost.Thread resource. The application needs in this case to map the resources if the need appear in his application.

The use cases presented should not be risky as there is no need to exchange the resources if I have understood.

HTH,
Vicente


_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users