[Webkit-unassigned] [Bug 63482] Allow non-main thread text drawing in ICU ports

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=63482





--- Comment #12 from Darin Adler <darin at apple.com>  2011-06-27 16:23:06 PST ---
(In reply to comment #10)
> > I think you still need to set this to nullptr in destroy().
> 
> I thought about this, but decided it was best to keep this as is. If I cleared
> the pool object inside of destroy it doesn't mean much if the object will
> be recreated on access (because of the lazy loading).

I don’t really understand. Sure, if you try to use the global data after destroying it, there will be a problem. But that’s not specific to your new data member. You can’t use the global data after it has been destroyed.

> Also, the sharedPool code never expects a null value

The sharedPool code will never get a null value, because it calls a function that allocates a new pool if it is zero. This is not an issue.

> OwnPtr guarantees this whether or not the destroy() happened or not.

Sorry, I don’t understand what you are saying OwnPtr guarantees.

> Clearing this in destroy would likely mean:
> 
>   - no more lazy loading or state so we don't want to create after we are destroyed
>   - handle a possible null value in sharedPool()?

It wouldn’t mean either of those things. It’s not legal to call sharedPool after calling destroy.

> Even the current approach has a possible issue where the GlobalData's could
> deconstruct a LayerPool that was returned from sharedPool(). Clearing it earlier
> in destroy() would make this slightly more possible.

I think you are misunderstanding. The destroy function exists so it can be called on worker threads. On normal threads it will be called from inside the destructor. So this timing thing you are talking about, a window of time after the destroy function is called and before the destructor, does not really exist.

> Does either approach sound better to you?

I think your new data member needs to match the rest of the class, and do the actual deallocation in destroy, not just in the destructor. Unless we eliminate the destroy function, which might be good. I don’t understand why worker threads need a different way to destroy the thread data, and it would be better if they did it by actually deallocating.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.