Hi, you shouldn't use the API with multiple threads because it is pretty much single-threaded. This may sound not great at first but having mutexes or something similar all over the place would make the whole framework quite complex.
Also the client-side API communicates mostly through sockets with the services which are split into multiple separate processes. So you already get some kind of implicit synchronization by using these sockets and have some kind of parallelism with those multiple services. So if you want to develop an application using the GNUnet framework, I would suggest putting all calls regarding GNUnet into one thread and parallelize the other parts of the application. For example if you're developing a graphical application, you can fork the main process into two (one for the GNUnet API and one for the GUI). I did pretty much that for cadet-gtk because GTK3 is also mostly single-threaded. I also would not recommend using two much threads in a simple application because it can cause issues, you may never find. Happy hacking, Jacki On Sat, 2021-02-27 at 16:05 +0000, Danny via Mailinglist for GNUnet developers wrote: > Also, may I ask? > Is there any problem with using the API functions on other threads > than > the one GNUNET_PROGRAM_run was called on? > > I am having weird segfaults/stack overlow errors at seemingly random > places. I'm calling the *_connect (and afterwards *_disconnect) > functions, and then some API calls, all from another thread, and I'm > worried I have somehow caused unspecified behavoir or something. > There is still no parallelism. I was thinking that since the API > calls > simply exchange process messages, it shouldn't matter from which > thread I'm exchanging them. Or am I wrong here? > > Anyway, > Thanks a lot. > Danny
signature.asc
Description: This is a digitally signed message part
