[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the scheduler about?

From: Schanzenbach, Martin
Subject: Re: What is the scheduler about?
Date: Sat, 27 Feb 2021 17:49:11 +0100

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.


> On 27. Feb 2021, at 17:43, Danny <> 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

Attachment: signature.asc
Description: Message signed with OpenPGP

reply via email to

[Prev in Thread] Current Thread [Next in Thread]