[vfer-users] vfer current cvs thread deadlocks on files larger than 1mb

[Markus K. <koe...@gm...>]

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