On Sunday 20 February 2005 17:58, Ludovic Court�s wrote: > Today, one hour, 7 minutes, 15 seconds ago, Christian Grothoff wrote: > > You are right in that the code does not _guarantee_ that the CPU load > > limitations will be satisfied. The assumption is, that if you cut out > > (enough of) the expensive computations, you will be blocking (on > > IO/networking events). Now, clearly that may not happen if there is "too > > much" network traffic (so that even with the cheapest algorithms, you > > cannot process all of the data). However, so far I had generally the > > impression that this only happened on systems that were imbalanced in > > terms of CPU vs. network capabilities (T1 line on a 386, to given an > > extreme example). > > Beside this, this may happen if gnunetd does only/mostly non-blocking > calls to select, read, and the likes (or calls with too little > timeouts). Is it the case?
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 ;-). Christian _______________________________________________ Help-gnunet mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnunet
