search for: my_free

...; is called when libnbd +no longer holds a reference to that object. + +To illustrate how this works with an example: + + struct write_completed_user_data *my_user_data; + void *buf; + + my_user_data = malloc (sizeof *my_user_data); + buf = malloc (512); + nbd_add_free_callback (nbd, my_user_data, my_free, NULL); + nbd_add_free_callback (nbd, buf, my_free, NULL); + nbd_aio_pwrite_callback (nbd, buf, 512, 0, + write_completed, my_user_data, 0); + +where C<my_free> is a simple wrapper around the L<free(3)> +function (we are not using the extra C<user_data> po...

...aggressive in > optimizing based on this metadata. > For example, do we really want to remove a call to a custom > allocator whose return value is unused (like we do for malloc)? If > so, we'll also need a metadata node to mark de-allocation functions > (so that sequences like my_free(my_malloc(xx)) are removed). You might want to restrict that to custom allocators that have an additional 'removable' attribute. Out of curiosity, does any of this potentially effect the presence or absence of 'inbounds' on GEP instructions? Thanks again, Hal > > Any feed...

...we should be very aggressive in optimizing based on this metadata. For example, do we really want to remove a call to a custom allocator whose return value is unused (like we do for malloc)? If so, we'll also need a metadata node to mark de-allocation functions (so that sequences like my_free(my_malloc(xx)) are removed). Any feedback on the issues described is highly appreciated! Thanks, Nuno

On Fri, 25 May 2012 17:43:52 +0200 Duncan Sands <baldrick at free.fr> wrote: > Hi John, > > On 25/05/12 17:22, John Criswell wrote: > > On 5/25/12 2:16 AM, Duncan Sands wrote: > >> Hi John, > >> > >>>>> I'm implementing the alloc_size function attribute in clang. > >>>> does anyone actually use this attribute? And if

...ng with the internal machinery to call > them. As written above this doesn't quite work. However it could work to pass an optional free function with the closure. In other words it would look like: struct nbd_closure { .cl = my_debug_fn, .user_data = foo, .free = my_free } cl; nbd_set_debug_callback (nbd, &cl); cl->free (cl->user_data) is called if cl->free != NULL when the closure is no longer used by the library. This is a bit of a change to the API however. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones...

...is unused (like we do for malloc)? No we don't, so LLVM's interface to malloc-like and calloc-like things would have to be reworked to extract out different kinds of knowledge. If so, we'll > also need a metadata node to mark de-allocation functions (so that > sequences like my_free(my_malloc(xx)) are removed). Maybe! Ciao, Duncan.

...; + > +C<ptr> is a pointer to the object (ie. the buffer or > +callback C<user_data>). C<cb (ptr)> is called when libnbd As written, your patch uses C<cb (ptr, user_data)>, so either this text is wrong, or you really don't need user_data. > + > +where C<my_free> is a simple wrapper around the L<free(3)> > +function (we are not using the extra C<user_data> pointer > +in this case): > + > + void my_free (void *ptr, void *) > + { > + free (ptr); > + } ...without user_data, you wouldn't need a my_free wrapper, but co...

As proposed here: https://www.redhat.com/archives/libguestfs/2019-August/msg00130.html I didn't actually read Eric's replies to that yet because I've been concentrating on writing these patches all day. Anyway here they are and I'll look at what Eric said about the proposal next. Rich.

More thoughts on callbacks, etc. following on from: https://www.redhat.com/archives/libguestfs/2019-July/thread.html#00184 Closure lifetimes ----------------- Closures could have a lifetime if we had a little bit of support from the C library. We would generate (from C only): nbd_set_free_<fn>_<closure> (nbd, free_closure); which calls free_closure (user_data) as soon as the

doesnt work for me Dne 29.5.2016 v 17:48 Niklas Larsson napsal(a): > Hi, > > > On 2016-05-27 18:28, Marek ?ervenka wrote: >> after downgrade to 13.8.2 >> May 27 18:21:06 ast kernel: asterisk[16286]: segfault at 1010024 ip >> b49162cd sp bfac0940 error 4 in >> libmysqlclient.so.16.0.0[b48f1000+12e000] >> >> after downgrade to 13.7.2 >>

...> No we don't, so LLVM's interface to malloc-like and calloc-like > things would have to be reworked to extract out different kinds of > knowledge. > > If so, we'll > > also need a metadata node to mark de-allocation functions (so that > > sequences like my_free(my_malloc(xx)) are removed). > > Maybe! > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- Hal Finkel Postdoc...