On Thu, Nov 5, 2009 at 2:01 PM, John Abd-El-Malek wrote:
>
>
> On Thu, Nov 5, 2009 at 1:42 PM, Jeremy Orlow wrote:
>
>> On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek wrote:
>>
>>>
>>>
>>> On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow wrote:
>>>
On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El
On Thu, Nov 5, 2009 at 1:42 PM, Jeremy Orlow wrote:
> On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow wrote:
>>
>>> On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
>>>
Over the last week, I've been making some changes
On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek wrote:
>
>
> On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow wrote:
>
>> On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
>>
>>> Over the last week, I've been making some changes to how threads are used
>>> in the browser process, with the g
On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow wrote:
> On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
>
>> Over the last week, I've been making some changes to how threads are used
>> in the browser process, with the goal of simplifying cross-thread access and
>> improving stability.
>>
On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
> Over the last week, I've been making some changes to how threads are used
> in the browser process, with the goal of simplifying cross-thread access and
> improving stability.
>
> *The problem*
> We were using a number of patterns that we
Very cool!
Could this idea be done in the render process? We try to keep the media
processing code off the render thread but we've been bitten using cached
MessageLoops which have been destructed (usually on tab close when the
render thread goes away).
On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El
I've updated the wiki. I was wary of putting this stuff up because of bit
rot, but since there's already documentation we won't be worse off.
As for the renderer process: this object would have to be recreated. I'd
prefer to keep ChromeThread just for one process to keep things clearer. I
think
On Tue, Nov 3, 2009 at 12:03 AM, Paweł Hajdan Jr.
wrote:
> On Tue, Nov 3, 2009 at 06:50, John Abd-El-Malek wrote:
>
>> *The solution*
>> 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask,
>> DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed
>> if the targ
On Tue, Nov 3, 2009 at 6:01 AM, Mike Pinkerton wrote:
>
> Can you put this information, as well as some examples for proper
> usage, on dev.chromium.org. I doubt this stuff is very well documented
> from the perspective of someone trying to use it, and this looks like
> a great start!!!
The plac
Can you put this information, as well as some examples for proper
usage, on dev.chromium.org. I doubt this stuff is very well documented
from the perspective of someone trying to use it, and this looks like
a great start!!!
On Tue, Nov 3, 2009 at 12:50 AM, John Abd-El-Malek wrote:
> Over the las
On Tue, Nov 3, 2009 at 06:50, John Abd-El-Malek wrote:
> *The solution*
> 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask,
> DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed
> if the target thread is known to outlive the current thread. The four
> sta
That sounds interesting, but there are still two changes remaining and other
unrelated changes have gone in in the meantime, so it wouldn't be an apple
to apple comparison. I can let you know when I'm done though (when the bug
is marked fixed).
On Mon, Nov 2, 2009 at 10:09 PM, Huan Ren wrote:
>
Cool! I could compare the builds before and after these changes to see
what difference it makes. Of course it also prevents future issues.
Huan
On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
> Over the last week, I've been making some changes to how threads are used in
> the browser p
13 matches
Mail list logo
