It uses bindings generated with "bindgen". I am not sure how well it plays
together with the scheduler actually.
You probably want to have libgnunetutil. Most of it does not rely on the
scheduler.
So you could start with "bindgen"-ing libgnunetutil only. Once you have those,
you can start buildin
Maybe I should have been a little more exact/clear in my wordings.
I don't mean every http request is handled in its own thread, I mean
all code that is executed for one particular request happens in the
same thread that it is assigned to.
Anyway, using one GNUNET_PROGRAM_run on each thread sounds
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.
BR
> 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 synta
You should notice that even the calls of GNUNET_SCHEDULER_add_now()
have to be on the same thread. So if you want to dispatch something
from another thread you have to implement some custom IPC or
synchronization first between your threads before calling any GNUnet
API. ^^'
However you can also st
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
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 r
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 mu
Almost none of the GNUnet APIs are expected to be thread-safe. Unless
you REALLY know what you are doing (basically, know for which APIs there
is an exception!), you must call all GNUnet APIs from the same thread.
On 2/27/21 5:05 PM, Danny via Mailinglist for GNUnet developers wrote:
> Also, may I
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 wi
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
Hey thanks,
Yeah that clarifies/explains it.
Now I have been able to connect to the identity service, create an ego,
and disconnect on shutdown so that it doesn't get stuck. :)
Thanks!
Danny
On Sat, 2021-02-27 at 10:32 +0100, Schanzenbach, Martin wrote:
> Hi,
>
> let us first try to unpack the
Hi,
let us first try to unpack the "normal" case (GNUNET_PROGRAM_run or run2 with
scheduler):
The scheduler is basically GNUnet's "main loop". It will run the tasks for
service communications, for example.
The scheduler intercepts all signals and handles them, including SIGTERM et al.
It also p
12 matches
Mail list logo
