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 > > > > > > > >