Segfaulting thread libraries and pools
[email protected] Wed, 28 Feb 2007 09:57:16 +0100
| Newsgroups | gmane.comp.gnu.ccrtp.devel |
|---|---|
| Message-ID | <[email protected]> |
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.