[Webkit-unassigned] [Bug 41790] Make FastMalloc more portable

[bugzilla-daemon at webkit.org]

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





--- Comment #10 from Patrick R. Gansterer <paroga at paroga.com>  2010-07-08 05:16:36 PST ---
(In reply to comment #9)
> ThreadSpecific.h allocates memory using FastMalloc, so it can’t be used within FastMalloc’s implementation.  It didn’t appear to be used by the attached patch anyway, so maybe that’s besides the point.
I need the following lines for WinCE and didn't wanted to copy them:
#ifndef TLS_OUT_OF_INDEXES
#define TLS_OUT_OF_INDEXES 0xffffffff
#endif

> I don’t think Threading.h is the right header to include.  The data types used all seem to come from ThreadingPrimitives.h, so why not include that instead?
> I’m also wary of introducing WTF types in to FastMalloc.  Many bits of code in WTF allocate memory in order to do their job, which isn’t something that’s sensible to do via the normal means from within the memory allocator.  WTF::createThread is one such function.
> I’m curious why this weird subset of FastMalloc was modified in this manner.  There’s a bunch of other code in FastMalloc that uses pthreads after all.
I ported the other code too to native windows, but when using WTF::createThread there is exactily this problem:
WTF::createThreadInternal (at least on windows) does a "new ThreadFunctionInvocation", which wants to be allocated via FastMalloc, and this results in an endless loop.

Is there a good way to reuse the current Mutex/ThreadCondition/ThreadSpecific stuff? Or do I need to implement it again?
Maybe we can only fix the Qt problem? What about QtWin?
I don't think that allocating Mutex and ThreadCondition via Fastalloc should be a problem? Any ideas about the exact Qt problem?

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