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
