search for: completion_user_data

...ersistIn/Out parameter then we need to + * register it as a global root and save that into the + * completion_callback.user_data so the root is removed on + * command completion. + *) + List.iter ( + function + | BytesPersistIn (n, _) | BytesPersistOut (n, _) -> + pr " completion_user_data->bufv = %sv;\n" n; + pr " caml_register_generational_global_root (&completion_user_data->bufv);\n" + | _ -> () + ) args; + let ret_c_type = C.type_of_ret ret and errcode = C.errcode_of_ret ret in pr " %s r;\n" ret_c_type; pr "\n";...

...;\n" n n + pr " %s_buf = nbd_internal_py_get_aio_buffer (%s);\n" n n; + pr " if (!%s_buf) goto out;\n" n; + pr " /* Increment refcount since buffer may be saved by libnbd. */\n"; + pr " Py_INCREF (%s);\n" n; + pr " completion_user_data->buf = %s;\n" n | Closure { cbname } -> - pr " /* Increment refcount since pointer may be saved by libnbd. */\n"; - pr " if (!PyCallable_Check (%s_user_data->fn)) {\n" cbname; + pr " %s.user_data = %s_user_data = alloc_user_data ();\n...

...rement the + * refcount on command completion. + *) + List.iter ( + function + | BytesPersistIn (n, _) | BytesPersistOut (n, _) -> + pr " /* Increment refcount since buffer may be saved by libnbd. */\n"; + pr " Py_INCREF (%s);\n" n; + pr " completion_user_data->buf = %s;\n" n; + | _ -> () + ) args; + (* Call the underlying C function. *) pr " ret = nbd_%s (h" name; List.iter ( @@ -4384,7 +4405,8 @@ let generate_python_methods_c () = pr " * and freed in the free_user_data function below.\n"; pr " */\...

Basically the same as this patch series, but for Python: https://www.redhat.com/archives/libguestfs/2019-August/msg00235.html plus adding the 590 asynch test at the end. Rich.

In this patch series we use the newly introduced free callback on the completion function to dererence the OCaml NBD.Buffer. I will make the same kind of change for Python later in a separate series. The completion function is always called at the C level, even if the OCaml program didn't use the optional argument. That's because the free callback doesn't run otherwise. There is a

...cribed in L<libnbd(3)/Completion callbacks>. > > Note that you must ensure C<buf> is valid until the command has > completed. Other parameters behave as documented in C<nbd_pread>."; While we're here, should we also mention that C<completion> and C<completion_user_data> remain valid until the command completes? Or is that overkill (the function pointer remains valid unless you dlclose() something providing it; and it's kind of obvious that you want the user data to remain valid). It may matter more for functions that don't take a buf (such as nbd_aio_...

..." }\n"; pr " else\n"; pr " %s.callback = NULL; /* we're not going to call it */\n" cbname @@ -447,7 +450,8 @@ let print_python_binding name { args; optargs; ret; may_set_error } = pr " Py_INCREF (%s);\n" n; pr " completion_user_data->buf = %s;\n" n; | _ -> () - ) args; + ) args; + pr "\n"; (* Call the underlying C function. *) pr " ret = nbd_%s (h" name; @@ -477,11 +481,20 @@ let print_python_binding name { args; optargs; ret; may_set_error } = | OFlags (n, _) -> pr &quo...

This is a combination of these two earlier series: https://www.redhat.com/archives/libguestfs/2019-August/msg00235.html https://www.redhat.com/archives/libguestfs/2019-August/msg00240.html plus changes to allow .callback = NULL / .free != NULL, and to reduce the complexity of freeing callbacks. Although it's rather long there's nothing complex here. We might consider squashing some

This applies on top of the OClosure v2 series posted a few minutes ago. Rich.