|
Boost : |
Subject: Re: [boost] [threadpool] new version v12
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-03 10:16:29
----- Original Message -----
From: "Giovanni Piero Deretta" <gpderetta_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, November 03, 2008 3:29 PM
Subject: Re: [boost] [threadpool] new version v12
>
> On Mon, Nov 3, 2008 at 3:26 PM, vicente.botet <vicente.botet_at_[hidden]>
> wrote:
>> ----- Original Message ----- From: "Anthony Williams"
>> <anthony.ajw_at_[hidden]>
>> To: <boost_at_[hidden]>
>> Sent: Monday, November 03, 2008 3:19 PM
>> Subject: Re: [boost] [threadpool] new version v12
>>
>>
>>>
>>> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>>>
>>>> ----- Original Message ----- From: "Anthony Williams"
>>>> <anthony.ajw_at_[hidden]>
>>>>> At least with fibers you *can* migrate the task to another thread, if
>>>>> your task is able to handle it.
>>>>
>>>> I don't see any major issue to migrate tasks when the blocking
>>>> function get() calls recursivelly to the working thread scheduler. Is
>>>> there one?
>>>
>>> If the task migrates across threads its ID changes, and thread locals
>>> change.
>>
>> So if the task do not depends on thread specific this is safe.
>>
>
> Is there any that doesn't? Even errno is usually thread specific, and
> most allocators have thread specific paths.
Sorry, I was not enough precise. If the task manage safely with the thread
specific this is safe, i.e. if the tasks stores the errno there is no issue
when migrating to another thread.
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk