Hi again! One day, 21 hours, 50 minutes, 20 seconds ago, Christian Grothoff wrote: > No, we pretty much use hardly any non-blocking calls for most of our IO > (there > are some exceptions for sockets, but they boil down to read/write calls that > center around a select or error handling) and pretty much all selects are > fully blocking. This is one reason why we have so many threads ;-).
>From what I can see with `grep PTHREAD_CREATE *.c' (in src/server), there should be 4 threads: the main thread which does nothing but wait for a signal, a TCP listener thread (the one calling `select ()'), two packet processing threads (created by `initCore ()'), and a "cron" thread (created in util/cron.c). The select-thread should spend most of its time waiting for messages. The two processing threads may as well spend a fair amount of time waiting for new packets. The cron thread sleeps at most 2 seconds in between two "jobs" and there seems to be a significant number of jobs. I believe this thread may create a certain level of almost permanent CPU activity; combined to the processing of incoming requests, this may be what yields to 100% of CPU usage at times. In such a scenario, the current decisions made depending on the value returned by `getCPULoad ()' can't help honor the CPU quota. Does this make sense? Note that `ps m' shows that my running `gnunetd' has 8 threads so I guess I'm still missing a few threads. :-) Do other people feel like gnunetd is eating too much CPU time or am I the only one noticing this? Thanks, Ludovic. _______________________________________________ Help-gnunet mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnunet
