Re: What is the scheduler about?

[Schanzenbach, Martin]

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

signature.asc
Description: Message signed with OpenPGP