Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-11-03 10:21:59

On Mon, Nov 3, 2008 at 4:16 PM, vicente.botet <vicente.botet_at_[hidden]> wrote:
> ----- 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.
>

Not really. Without compiler help (available on VC++ but not on GCC)
there is no way out.

See: http://www.crystalclearsoftware.com/soc/coroutine/coroutine/coroutine_thread.html

for an explaination of the problem.

-- 
gpd