[systemd-devel] sd_bus_add_match callback
Question regarding sd_bus_add_match (sd-bus.c): Is it acceptable (or recommended) to use the same callback for multiple signal match and then using the userdata parameter to distinguish among the different signals? See the sample code below for a reference of what I am trying to do. /*Beginning=*/ int callback(sd_bus_message *message, void *userdata, sd_bus_error *error) { //there should be a lock applied here? if(get_signal_id(userdata) == 1) { //do something } } int main(...) { r = sd_bus_add_match(bus, &slot, "type='signal'", test_callback, userdata); int r; sd_bus *bus = NULL; sd_event *event = NULL; sd_bus_slot *slot = NULL; r = sd_bus_default_system(&bus); assert(r >= 0); r = sd_event_default(&event); assert(r >= 0); void *userdata1 = set_signal_id(1); r = sd_bus_add_match(bus, &slot, "type='signal',interface='org.interface2'", callback, userdata1); void *userdata2 = set_signal_id(2); r = sd_bus_add_match(bus, &slot, "type='signal',interface='org.interface1'", callback, userdata2); r = sd_event_loop(event); assert(r >= 0); bus = sd_bus_flush_close_unref(bus); slot = sd_bus_slot_unref(slot); event = sd_event_unref(event); } /*End =*/ I appreciate your help and your time. Thank you, David J (ema...@icloud.com) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd_bus_add_match callback
Hello Systemd developers! > I asked this question earlier but I haven’t gotten any reply so I thought > asking again. > Question regarding sd_bus_add_match (sd-bus.c): > > Is there any bad consequences to use the same callback for multiple signal > match and then using the userdata parameter to distinguish among the > different signals? See the sample code below for a reference of what I am > trying to do. > > /*Beginning=*/ > int callback(sd_bus_message *message, void *userdata, sd_bus_error *error) { > //there should be a lock applied here? > if(get_signal_id(userdata) == 1) { > //do something > } > } > > int main(...) { > r = sd_bus_add_match(bus, &slot, "type='signal'", test_callback, userdata); > int r; > sd_bus *bus = NULL; > sd_event *event = NULL; > sd_bus_slot *slot = NULL; > > r = sd_bus_default_system(&bus); > assert(r >= 0); > > r = sd_event_default(&event); > assert(r >= 0); > > void *userdata1 = set_signal_id(1); > r = sd_bus_add_match(bus, &slot, > "type='signal',interface='org.interface2'", callback, userdata1); > > void *userdata2 = set_signal_id(2); > r = sd_bus_add_match(bus, &slot, > "type='signal',interface='org.interface1'", callback, userdata2); > > r = sd_event_loop(event); > assert(r >= 0); > > bus = sd_bus_flush_close_unref(bus); > slot = sd_bus_slot_unref(slot); > event = sd_event_unref(event); > } > > /*End =*/ > > I appreciate your help and your time. > > Thank you, > David J (ema...@icloud.com) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd_bus_add_match callback
Giacinto, Thanks for further explaining my email. Lennart, Thank you for your feedback. What I am doing is writing an sd-bus interface and a client code, which is only interested in specific signal information. So the interface has to offer minimal API’s. The interface has one callback to handle all the signal callbacks, processes the messages and populates the information for the client code. If you have a better resolution please share. Side note: I really enjoyed using the sd-bus API’s! Thank you for the awesome library. DJ Sent from my iPhone > On Apr 10, 2020, at 10:51 AM, Giacinto Cifelli wrote: > > hi Lennart, > >> On Fri, Apr 10, 2020 at 2:14 PM Lennart Poettering >> wrote: >> >>> On Do, 09.04.20 14:12, David J (ema...@icloud.com) wrote: >>> >>> Hello Systemd developers! >>> >>>> I asked this question earlier but I haven’t gotten any reply so I thought >>>> asking again. >>> >>>> Question regarding sd_bus_add_match (sd-bus.c): >>>> >>>> Is there any bad consequences to use the same callback for >>>> multiple signal match and then using the userdata parameter to >>>> distinguish among the different signals? See the sample code below >>>> for a reference of what I am trying to do. >> >> No sure why one would do that, but the userdata argument is something >> you can use any way you like. Most people stick some context object >> pointer in it, but it's entirely fine to place anything else there, >> for example an enum that you cast to a pointer. > > If I understand correctly David's question, he wants to know if he got > triggered twice on the same event in a single client. > I am also interested because it could be simple for some application > to be triggered by two events instead than re-firing a message > internally. > >> >> Lennart >> >> -- >> Lennart Poettering, Berlin >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > Thank you, > Giacinto ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] sd-bus memory check
Hello! This is in regards to sd-bus function "sd_bus_open_system", where Valgrind reports possible memory leak. See the following code: mem_test.c: #include #include #include int main(int argc, char *argv[]) { sd_bus *bus = NULL; int r = sd_bus_open_system(&bus); if (r < 0) { fprintf(stderr, "sd_bus_open_system: %s\n", strerror(-r)); } bus = sd_bus_unref(bus); } compile command: gcc mem_test.c -o mem_test `pkg-config --cflags --libs libsystemd` Valgrind output: ==4452== Memcheck, a memory error detector ==4452== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==4452== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==4452== Command: ./mem_test ==4452== ==4452== ==4452== HEAP SUMMARY: ==4452== in use at exit: 7,736 bytes in 12 blocks ==4452== total heap usage: 17 allocs, 5 frees, 8,045 bytes allocated ==4452== ==4452== LEAK SUMMARY: ==4452== definitely lost: 0 bytes in 0 blocks ==4452== indirectly lost: 0 bytes in 0 blocks ==4452== possibly lost: 3,640 bytes in 11 blocks ==4452== still reachable: 4,096 bytes in 1 blocks ==4452== suppressed: 0 bytes in 0 blocks The question is am I doing anything wrong here? Why Valgrind thinks there "might" be memory leak? The interesting part is if I use "sd_bus_open_system", Valgrind is all happy and no warnings at all! Thank you, David J. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-bus memory check
Will, thank you very much. I spent my Sunday debugging this thing! Using sd_bus_flush_close_unref() eliminated the memory leak! Appreciate your help! On April 12, 2020 at 9:20 PM, William Kennington wrote: You are probably looking for sd_bus_flush_close_unref() for this usecase. On Sun, Apr 12, 2020 at 11:00 AM David J wrote: Hello! This is in regards to sd-bus function "sd_bus_open_system", where Valgrind reports possible memory leak. See the following code: mem_test.c: #include #include #include int main(int argc, char *argv[]) { sd_bus *bus = NULL; int r = sd_bus_open_system(&bus); if (r < 0) { fprintf(stderr, "sd_bus_open_system: %s\n", strerror(-r)); } bus = sd_bus_unref(bus); } compile command: gcc mem_test.c -o mem_test `pkg-config --cflags --libs libsystemd` Valgrind output: ==4452== Memcheck, a memory error detector ==4452== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==4452== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==4452== Command: ./mem_test ==4452== ==4452== ==4452== HEAP SUMMARY: ==4452== in use at exit: 7,736 bytes in 12 blocks ==4452== total heap usage: 17 allocs, 5 frees, 8,045 bytes allocated ==4452== ==4452== LEAK SUMMARY: ==4452== definitely lost: 0 bytes in 0 blocks ==4452== indirectly lost: 0 bytes in 0 blocks ==4452== possibly lost: 3,640 bytes in 11 blocks ==4452== still reachable: 4,096 bytes in 1 blocks ==4452== suppressed: 0 bytes in 0 blocks The question is am I doing anything wrong here? Why Valgrind thinks there "might" be memory leak? The interesting part is if I use "sd_bus_open_system", Valgrind is all happy and no warnings at all! Thank you, David J. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel