[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 18:26:11 +0100

In that case it might be worth the effort to just write the service APIs
in Rust or try gnunet-rs. It may save you a lot of pain.


> On 27. Feb 2021, at 18:00, Danny <> wrote:
> 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 <>
>>> 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]