[Ccrtp-devel] Segfaulting thread libraries and pools

[Kovacs . Ferenc . 5]

Hi,

I try to understand, and after that, use the ccRTP library, but I experienced
some difficulties.

I started with the applications "demo/rtpsend.cpp" and "demo/rtplisten.cpp". I
created threads from Sender and Listener, and I put the sending and receiving
functionality into the threads' run() function. This way I was able to create,
any number of threads on both side. With a few threads it worked pretty well,
but with increasing the number of threads (the number of listeners and senders
on both side), the number of segfaults increased as well... According to
Purify, the segfaults are coming from the thread library. I'm using Fedora
Core 3 (2.6.9/2.6.21-rc1). I tried both the NPTL/LinuxThreads libraries, but
there was no significant difference, in the number of segfaults, between them.
Sometimes I got "double free, or corruption" runtime errors from Glibc. 20-20
threads on both side, means 40-40 threads in real, becouse the Sender and
Receiver are in a separate thread, and there's a thread for the stack itself
on both side. Has anybody experienced the same problems, or I did something
wrong?

Maybe, with using a pool I can avoid these problems, but there's more  
work with
it, to make it work. I'm not afraid of work anyway, but I don't know if I'm
right or not. :) As far as I know, SingleRTPSessionPool is handling only the
stack (like SingleThreadRTPSession), in the run() function. The application's
responsibilty is to receive and send with putData()/getData(). With every
session in a separate thread, it was easy, becouse every session had a  
separate
application. But now, I'll have one application, from I need to handle all the
sessions in the pool. Is it right? Should I write my own scheduler in the
application to make it work? This scheduler would select a session some way,
and it would call getData()/putData() on it...

Thanks in advance, and forgive me for this long letter.

Regards,
Ferenc Kovacs


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.