search for: lock_guard

...text, and expose this and the module count. Then in the IR-compiling layer of the JIT we could have something like: // Compile finished, time to deallocate the module. // Explicit deletes used for clarity, we would use unique_ptrs in practice. auto &Ctx = Mod->getContext(); delete Mod; std::lock_guard<std::mutex> Lock(Ctx->getMutex()); if (Ctx.getNumModules()) delete Ctx; Another option would be to invert the ownership model and say that each Module shares ownership of its LLVMContext. That way LLVMContexts would be automatically deallocated when the last module using them is destruc...

...yer of the JIT we >> could have something like: >> >> // Compile finished, time to deallocate the module. >> // Explicit deletes used for clarity, we would use unique_ptrs in >> practice. >> auto &Ctx = Mod->getContext(); >> delete Mod; >> std::lock_guard<std::mutex> Lock(Ctx->getMutex()); >> if (Ctx.getNumModules()) >> delete Ctx; >> >> Another option would be to invert the ownership model and say that each >> Module shares ownership of its LLVMContext. That way LLVMContexts would be >> automatically d...

...t;>>> >>>> // Compile finished, time to deallocate the module. >>>> // Explicit deletes used for clarity, we would use unique_ptrs in >>>> practice. >>>> auto &Ctx = Mod->getContext(); >>>> delete Mod; >>>> std::lock_guard<std::mutex> Lock(Ctx->getMutex()); >>>> if (Ctx.getNumModules()) >>>> delete Ctx; >>>> >>>> Another option would be to invert the ownership model and say that each >>>> Module shares ownership of its LLVMContext. That way LLVMCo...

...gLayer.cpp. I found this first by adding an additional debug statement (highlighted) thinking the `reinterpret_cast` may be at fault for the key mismatch. I never saw this print and I then realized my “Adding” vs. “Registering” mistake. // Run EventListener notifyLoaded callbacks. { std::lock_guard<std::mutex> Lock(RTDyldLayerMutex); dbgs() << "Registering MemMgr " << MemMgr << "\n"; auto LOIItr = LoadedObjInfos.find(MemMgr); assert(LOIItr != LoadedObjInfos.end() && "LoadedObjInfo missing"); for (auto *L : EventList...

On Wed, Nov 28, 2018 at 6:25 PM Chris Lattner via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Generally no IMO, because the cases that produce optional are not obvious. > Just to say, +1 from me too. > > > * Can we use auto in c++14 lambda arguments with llvm::find_if(C, > [](const auto& i) { ... }) for example? > > * We need to use auto for structured

Hi Adam, Calls to the listeners should be protected by the RTDyldLayerMutex. Could you apply the attached patch and share the debugging output from one of the failing runs? Regards, Lang. On Wed, May 20, 2020 at 8:00 PM David Blaikie <dblaikie at gmail.com> wrote: > +Lang > > On Wed, May 20, 2020 at 4:44 PM Straw, Adam D via llvm-dev < > llvm-dev at lists.llvm.org>