Yeah, the loader lock is held the entire time while in the DLL main. The lock allows re-entrance, but if you do anything that starts another thread and then tries to dynamically load a DLL you'll get a deadlock. Unfortunately, it's very hard to predict what will cause a dynamic load (or one of the other actions which cause the lock to be taken). (OK...just read that article....I didn't really add much information...oh well :-)
Unfortunately, I don't know anything about OleInitialize specifically. J On Mon, Sep 28, 2009 at 10:59 PM, Andrew Scherkus <[email protected]>wrote: > I've read somewhere before that you should do as little as possible inside > DllMain. Something like this comes to mind: > http://blogs.msdn.com/oldnewthing/archive/2007/09/04/4731478.aspx > > Is it worth trying to defer calling OleInitialize? > > <http://blogs.msdn.com/oldnewthing/archive/2007/09/04/4731478.aspx>Andrew > > On Mon, Sep 28, 2009 at 9:15 PM, Darin Fisher <[email protected]> wrote: > >> I was pulling my hair out trying to figure out how my change could have >> caused the browser_tests to hang. So, I removed my patch and rebuilt. >> Still it hung. >> It turns out that we are calling OleInitialize within DllMain. It seems >> as though we are tripping up on the loader lock. >> >> Has anyone else seen this problem? >> >> -Darin >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
