search for: weak_ptr

...icationPoolServerExecutable.cpp:553) Thread ''Status report thread'': in ''void Passenger::ApplicationPoolStatusReporter::threadMain()'' (ApplicationPoolStatusReporter.h:100) Thread ''Client 6'': in ''void Client::threadMain(boost::weak_ptr<Client>)'' (ApplicationPoolServerExecutable.cpp:406) Thread ''Client 7'': in ''void Client::threadMain(boost::weak_ptr<Client>)'' (ApplicationPoolServerExecutable.cpp:406) Thread ''Client 10'': in ''void Client:...

...t;> return shared_from_this(); >> } >> }; >> >> int main() >> { >> auto a = prefix::make_shared<foo>(); >> auto b = a->get_sptr(); >> return 0; >> } >> >> This compiles fine, but throws a weak_ptr exception at runtime. >> I'm aware, that the implementation requires, that >> enable_shared_from_this needs to be publicly inherited, but as a first >> time user, I had to find this out the hard way, as documentations (I >> use, ie. cppreference.com) don't mention it...

...prefix::enable_shared_from_this<foo> { public: prefix::shared_ptr<foo> get_sptr() { return shared_from_this(); } }; int main() { auto a = prefix::make_shared<foo>(); auto b = a->get_sptr(); return 0; } This compiles fine, but throws a weak_ptr exception at runtime. I'm aware, that the implementation requires, that enable_shared_from_this needs to be publicly inherited, but as a first time user, I had to find this out the hard way, as documentations (I use, ie. cppreference.com) don't mention it, probably because it's not a...

On Thu, Jul 17, 2014 at 4:45 PM, Alp Toker <alp at nuanti.com> wrote: > > On 18/07/2014 02:21, David Blaikie wrote: >> >> Are people OK with/prefer the use of owning smart pointers in APIs? > > > I think smart pointers are great to use for storage, or as struct members > where there's actually a clear need for ownership. Just by virtue of getting > rid of

...Oct 19, 2016 at 6:24 PM, Benjamin Kramer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > In terms of performance shared_ptr has a number of disadvantages. One > is that it always uses atomics even though most IntrusiveRefCntPtrs > are used in single-threaded contexts. Another is weak_ptr adding a lot > of complexity to the implementation, IntrusiveRefCntPtr doesn't > support weak references. > > With that it's hard to make a case for changing uses of > IntrusiveRefCntPtr as it's a non-trivial amount of work > (IntrusiveRefCntPtr binds the reference cou...

...iler to make objc mechanisms friendly to the newer features of c++? For instance... 1) making blocks movable so that they can capture things like unique_ptr<> and still be moved off the stack 2) making @property declarations work with move-only types like unique_ptr<> 3) enabling std::weak_ptr<> to weakly store an objc pointer under ARC. (see radar: 31177975) 4) add a mechanism to allow template metaprogramming to make full use of selectors. (see radar: 30812297)

why llvm contains IntrusiveRefCntPtr instead of using only std::shared_ptr? IntrusiveRefCntPtr widely used in llvm and clang source code. Due to better performance? for example in main func of clang frontend: int cc1_main(ArrayRef<const char *> Argv, const char *Argv0, void *MainAddr) { ensureSufficientStack(); std::unique_ptr<CompilerInstance> Clang(new CompilerInstance());

...> management might help... > > Attached is a patch that changes this allocation to use shared_ptr, > perhaps it'll address the bug? > > (ideally we shouldn't need the intrusive ref counting > (std::enable_shared_from_this) but instead have a weak_set that has > std::weak_ptr in it & implicitly removes elements as they become null > (probably on a harvesting schedule, rather than with a direct callback as > is currently implemented))​ > pbqp_leak.diff > <https://docs.google.com/file/d/0B0jpkch3iC_7TXFVU2hCcUpfZXM/edit?usp=drive_web> > ​ > &g...

...chanisms friendly to the newer features of c++? For instance... > > 1) making blocks movable so that they can capture things like unique_ptr<> and still be moved off the stack > 2) making @property declarations work with move-only types like unique_ptr<> > 3) enabling std::weak_ptr<> to weakly store an objc pointer under ARC. (see radar: 31177975) > 4) add a mechanism to allow template metaprogramming to make full use of selectors. (see radar: 30812297) > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm...

...asses I think about having the following intrinsics: ptr = cast_untyped_to_nonshared(ptr) // e.g. used after allocation ptr = cast_to_shared_irreversible(ptr) // basically a gateway to other threads nonhared_acquire(ptr) nonshared_release(ptr) shared_acquire(ptr) shared_release(ptr) I also want weak_ptr at a later stage, but leave it out for now to keep the complexity manageble. Is this idea completely unreasonable? Ola. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201118/14f27ce0/attachment.html>

...d_to_nonshared(ptr) // e.g. used after allocation >> ptr = cast_to_shared_irreversible(ptr) // basically a gateway to >> other threads >> nonhared_acquire(ptr) >> nonshared_release(ptr) >> shared_acquire(ptr) >> shared_release(ptr) >> >> I also want weak_ptr at a later stage, but leave it out for now to >> keep the complexity manageble. >> >> Is this idea completely unreasonable? The main problem for this sort of optimization is that it is difficult to do on an IR like LLVM’s, where the semantic relationships between values that...

...PM, Benjamin Kramer via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> In terms of performance shared_ptr has a number of disadvantages. One >> is that it always uses atomics even though most IntrusiveRefCntPtrs >> are used in single-threaded contexts. Another is weak_ptr adding a lot >> of complexity to the implementation, IntrusiveRefCntPtr doesn't >> support weak references. >> >> With that it's hard to make a case for changing uses of >> IntrusiveRefCntPtr as it's a non-trivial amount of work >> (IntrusiveRefCntPtr...

...i.e. allow immortal BlockAddress and ConstantGlobalValue values while _also_ allowing us to delete GlobalValues and BasicBlocks. For this mechanism, we can let ourselves be inspired by mlir::SymbolRefAttr, which uses strings for the linkage. Alternatively (and perhaps preferably), we could use a weak_ptr-like mechanism. This can be very efficient, since each GlobalValue and BasicBlock only ever needs to have a single instance of ConstantGlobalValue and BlockAddress referring to it, respectively, so a simple back-link is sufficient. 2. Change setOperand to only update use lists of Argument and Inst...

> On 4 Aug 2016, at 06:27, Serge Rogatch <serge.rogatch at gmail.com> wrote: > > Hi Dean, > > I have a question about the following piece of code in compiler-rt/trunk/lib/xray/xray_trampoline_x86.S : > movq _ZN6__xray19XRayPatchedFunctionE(%rip), %rax > testq %rax, %rax > je .Ltmp0 > > // assume that %r10d has the function id. > movl %r10d,

Hi Lang, In PBQPBuilderWithCoalescing::build, around line 360, we have code looking like: … PBQP::Vector newCosts(g.getNodeCosts(node)); addPhysRegCoalesce(newCosts, pregOpt, cBenefit); g.setNodeCosts(node, newCosts); … I suspect the leak occurs around the setNodeCosts method, and I have trouble understanding how it handles the case where the node already has costs. It seems to

...rinsics: > > ptr = cast_untyped_to_nonshared(ptr) // e.g. used after allocation > ptr = cast_to_shared_irreversible(ptr) // basically a gateway to other threads > nonhared_acquire(ptr) > nonshared_release(ptr) > shared_acquire(ptr) > shared_release(ptr) > > I also want weak_ptr at a later stage, but leave it out for now to keep the complexity manageble. > > Is this idea completely unreasonable? LLVM has intrinsics for Objective-C ARC (https://llvm.org/docs/LangRef.html#objective-c-arc-runtime-intrinsics) and I think there are also some optimizations passes for t...

> On Mar 20, 2020, at 12:34 PM, Nicholas Krause <xerofoify at gmail.com> wrote: > >> >> The problem isn’t constants or functions themselves, it is that they are instances of llvm::Value. Everything that walks a use/def list would have to run code that checks for this, and every call to inst->setOperand() would have to do locking or conditional locking. This would be

...LF? Linker?) requirement that one entry must be 32-bytes, or aligned at 32 bytes, etc.? Thanks, Serge On 4 August 2016 at 19:29, Serge Rogatch <serge.rogatch at gmail.com> wrote: > Yes, double-checking on the handler side whether its resources are still > operational, e.g. by calling weak_ptr::lock() may be a better idea than > elimination of spurious handler calls in XRay at a cost of heavy > synchronization objects. Ok, let's live with spurious handler calls. > > Cheers, > Serge > > On 4 August 2016 at 10:57, Dean Michael Berris <dean.berris at gmail.com&gt...

...ng const&), int, std::allocator<int>, std::vector>(char const*, char const*, char, int (*)(std::string const&), std::vector<int, std::allocator<int> >&)"}, {"_ZN2MF12_GLOBAL__N_114WeakCallHelperINS0_15DecodeQueueImplEEEvRKN5boost8functionIFvvEEERKNS3_8weak_ptrIT_EE", "void MF::(anonymous namespace)::WeakCallHelper<MF::(anonymous namespace)::DecodeQueueImpl>(boost::function<void ()> const&, boost::weak_ptr<MF::(anonymous namespace)::DecodeQueueImpl> const&)"}, {"_ZZN4NIds4NStr14TCStrAggregateINS0_13TCTCSt...