From: Markus K. <koe...@gm...> - 2006-05-02 04:47:42
|
Hi, I compiled vfer current cvs on a debian & gentoo host in my lan, and hit some strange borders. both boxes are single cpu boxes, so smp/ht here. I was able to transfer a 1mb file at something like 22mbit, larger files like 100mb or 300mb would either deadlock the server, the client, or interrupt with an 'error', the server claims the client is guilty, the client disconnects with an error. I already profiled the code, and checked where to find the deadlocks, (not how to defeat them), so if these problems are not known, drop me a line and I'll followup with a more complete bugreport. From my point of view the whole threading used for the socketio is far to complex for the task itself, incomplete and therefore pretty error prone, for example grep pthread_mutex_trylock * -R | wc 0 0 0 no checking for *possible* deadlocks grep pthread_cond_ * -R src/api.c: pthread_cond_init(&skt->cond_readable, NULL); src/globals.h: pthread_cond_t cond_readable; src/globals.h: pthread_cond_t cond_writeable; src/globals.h: pthread_cond_t cond_exception; src/packet.h:// pthread_cond_t cond; no signaling to tell a thread a mutex got unlocked, and a new ressource is availible. my approach was to rewrite the socket io threadless and nonblocking, as the whole protocol implementation is useless (as it can neither be measured nor improved), if the socketio is unreliable due to threading problems. MfG Markus Koetter |