Re: What is the scheduler about?

[Danny]

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.jong@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
> >
> >
> >
> >