>> This makes it impossible to correctly shut down WebKit at runtime on this topic, i see that few singleton/global objects (ResourceHandleManager, Cache, allPages(Page.cpp) ) and possibly more are not getting destructed when webview is closed on the linux/gtk port. I dont know if this is an intended behavior or a bug, but this could be an issue in cases where you want to do a shut down only of webkit library. comments?
thanks, Zaheer On Wed, Sep 17, 2008 at 12:58 AM, Paul Pedriana <[EMAIL PROTECTED]> wrote: > You are correct, though non-PODs are intended to go through the base-case > operator new, whereby this wouldn't apply. The newObject template would have > applicability only to PODs or even just built in types like int/char. If > somehow it was deemed that this means was needed for non-PODs, the typical > solution is to use a macro, as in: > > #define newObject(Type) new(fastMalloc(sizeof(Type)) Type > > This has some advantages beyond argument passing over the template > solution. We've used this approach fairly successfully on a large scale at > my company. > > Paul > > > > Hi, > I just wonder how you can pass arguments to your new operator when they are > mandatory (no default constructor), in the following case: > > class Foobar{ > public: > Foobar(int a,char* b); > }; > class Barfoo{ > public: > Barfoo(char* a); > } > > Foobar* myFoobar=newObject<Foobar>( ?????? ); > Barfoo* myBarfoo=newObject<Barfoo>( ?????? ); > > Reading your patch, I don't think this testcase will work... will it? > > Fred > > > > Le Tuesday 16 September 2008 à 20:28, Paul Pedriana a écrit : > > > >> I'm curious to see the patch (just to give an idea how > >> big the changes would be). Do you have it somewhere? > > The patch is at: https://bugs.webkit.org/show_bug.cgi?id=20422. > I don't think this is a terribly difficult thing to implement (though > I don't mean to imply that it's trivial either). It might take a couple > iterations to make sure all instances are handled, though. I searched > the code and found a couple thousand instances of the keyword 'new', > though most of those would fall under the case of the base class operator. > > >> Ah I see now. So you want to isolate the malloc from > >> WebKit module. Furthermore, you want to be able to > >> "kill" WebKit *only* when something weird happens, > >> am I correct? > > I want to be able to shut down WebKit at any time, and possibly restart it. > If WebKit is used as a library within an application instead of being the > application itself, then you want to initialize it when needed, but when > it's > no longer needed then you want to shut it down. Think of computer games > like Grand Theft Auto whereby you are a character walking around the > world investigating something; and your character walks up to a computer > in the game and uses it to connect to the real web (using an embedded > WebKit) > to search for live-generated info for a while. When the character shuts off > the virtual computer, the game needs the resources of that computer to > go away, as the game needs to recover the RAM for the next thing the user > does. It significantly improves heap fragmentation of that WebKit instance > ran in a single contiguous block of memory such that when it went away > there is a nice big clean space left over. > > That being said, your original case of killing WebKit when something weird > happens is also a practical use case. Such a thing might in fact be memory > exhaustion due to fragmentation. > > Paul > > > > The primary benefit of being able to override operator new is to be able > to redirect all allocations for a library to a user-specified heap. With > global operator new, allocated WebKit memory is mixed in with the rest > of the application memory and there is no practical way to tell them > apart or sequester them. This makes it impossible to correctly shut down > WebKit at runtime, since you don't know where its memory is. A side > benefit related to this is that this allows for better memory metrics > gathering. > > > Ah I see now. So you want to isolate the malloc from WebKit module. > Furthermore, you want to be able to "kill" WebKit *only* when something > weird happens, am I correct? > > > > The proposal provides for a base class that overrides global operator > new. So any allocated classes use the same syntax as usual. Most of the > source code would fall under this. > > > Yes, that is true. > > > > For the case of non-class-based memory allocations (e.g. raw char > array), the proposal provides a newObject and newArray template > function. So instead of 'new int' you would way 'newObject<int>' and > instead of 'new char[32]' you would say 'newArray<char>(32)'. However, > there is an alternative approach which is to provide a custom operator > new type, like so: > struct WTF{}; > void* operator new(size_t size, WTF); > > and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the > conventional solution to namespacing operator new, where the C++ > standard doesn't allow for operator new being in a C++ namespace. > Perhaps this syntax is preferable. This can be #defined to simply newWTF > if desired, then it is practically identical to existing global new > syntax. > > FWIW, I have been testing the proposed patch in my copy and so far it > has been fine, but that of course includes only my uses. > > > I'm curious to see the patch (just to give an idea how big the changes > would be). Do you have it somewhere? > > > _______________________________________________ > webkit-dev mailing [EMAIL > PROTECTED]://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev