Re: Fwd: Re: What is the scheduler about?

[TheJackiMonster]

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: This is a digitally signed message part