In that case it might be worth the effort to just write the service APIs in Rust or try gnunet-rs. It may save you a lot of pain.
BR > On 27. Feb 2021, at 18:00, Danny <danny.de.j...@protonmail.com> wrote: > > Yeah thank you, but actually I'm using Rust, and I like the web servers > available for it and its async/await syntax. :) > > And besides I think wrapping gnunet in Rust is enough work already. > > Groetjes, > Danny > > On Sat, 2021-02-27 at 17:49 +0100, Schanzenbach, Martin wrote: >> If you are not picky about the web server you can integrate >> libmicrohttpd with >> gnunet as they can share the scheduling. We do that, for example, for >> the >> gns proxy (gnuent-gns-proxy) and the rest service. >> >> BR >> Martin >> >>> On 27. Feb 2021, at 17:43, Danny <danny.de.j...@protonmail.com> >>> wrote: >>> >>> Hey, >>> >>> Yeah so I was trying to run a webserver (for the UI) alongside >>> gnunet. >>> I made it so that gnunet starts on the main thread, and after it is >>> initialized, I spawn a thread for the http server. The http server >>> has >>> its own 'event/message loop', which handles each http request in >>> one >>> thread, but multiple workers exist that handle http requests. >>> >>> But essentially in my case each connection to a gnunet service is >>> utilized on only one tghread. I thought this would probably be safe >>> (enough). >>> But now that I think about it, I can see the issue if the API calls >>> try >>> to modify the same variables (like a message queue) that the >>> scheduler >>> uses (considering they access it from different threads). >>> >>> I guess I'll just have to dispatch all the api calls done on the >>> web >>> server thread(s) with GNUNET_SCHEDULER_add_now. >>> >>> Danny. >>> >>> On Sat, 2021-02-27 at 17:24 +0100, TheJackiMonster wrote: >>>> 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: Message signed with OpenPGP
