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

[Ivan B. <iv...@cs...>]

On 5/2/06, Markus Koetter <koe...@gm...> wrote:
>
> It is a threading deadlock, maybe the protocol bugs too, but what I saw
> was a definitly a threading deadlock.
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  7249 me        16   0 56716  22m  692 S 90.1  2.2   3:16.98 vfer
>
> select(0, NULL, NULL, NULL, {1, 0})     =3D 0 (Timeout)
> futex(0x8062988, FUTEX_WAIT, 2, NULL
>
> and then the cpu peaks at 99% for the process.
>
> =3D=3D8071=3D=3D    at 0x1B949199: __lll_mutex_lock_wait (in
> /lib/tls/libpthread-2.3.6.so)
> =3D=3D8071=3D=3D    by 0x804F105: Control_Recv (control.c:600)
> =3D=3D8071=3D=3D    by 0x804B1ED: vfer_recv (api.c:930)
> =3D=3D8071=3D=3D    by 0x804AF44: vfer_recvfile (api.c:872)
> =3D=3D8071=3D=3D    by 0x805D3C8: main (vfer_rcp.c:407)

I haven't seen deadlocks such as this in my testing. Send me more info
so I can try to reproduce what you're seeing.

> Murphys law says "Interchangeable parts-won't", and the socket io used
> in vfer was not even planned as interchangeable, replacing it will be
> the hell. One has to get a _real_ close view on all parts of the code,
> draft a new layout, and restructure the existing code, while rewriting
> the socket io.

Its actually not very difficult to impose a nonthreading model.
Reading and writing is relegated to reader.c and writer.c which are
impl as two threads. Meshing them together is not very difficult.
Instead of building up a private packet buffer, the packets can be
handled as they come in and that removes almost all mutexes.
Appropriate functions from control.c such as the main thread loop
(ControlT) can be modified to proccess packets as they come in,
instead of blocking until they appear in the packet buffer. If each
socket is handled by a different thread, the modifications you have to
make are not very difficult. I'll be working on this project over the
summer as well, and will provide whatever help and code guidance that
will be necessary to make new modifications and future development
easy. The code is very well documented so getting to know it isn't
very difficult either. These are my personal opinions, you are
welcomed to disagree :-)


ivan.