Hi,... On Wed, Mar 15, 2006 at 11:42:17AM +0100, Jörgen Terner wrote: > > Hi all! > > I've tried to use the SingleRTPSessionPool. After several crashes I realized > that it is not thread safe. Insertions and deletions are safe but the main > loop is not! There is little point in protecting insertions and deletions if > the code that reads the list is not protected. > > I've modified the pool-class so that it seems to work but because the number > of concurrent sessions are quite large (Minimum requirement ~500) the thread > that serves the list of sessions is not given enough time to to its job. I've > tried to increase the thread priority but still, the sessions are not served > fast enough. >
Yes, the session pool stuff is quite "experimental". So it looks like after your modifications it becomes quite stable and able to handle a large number of sessions? > My current implementation instead inserts "session-jobs" into a thread pool > with a larger amount of threads. The run-method of the session-jobs I've > copied from the SingleThreadRTPSession class as in the code below. After each > run, the jobs are reinserted into the pool until they are marked as stopped. > I'm not currently using commoncpp:s thread-library så I had to comment out > the calls to setCancel. Potential problem? > I would say it depends on how you handle threading, but as long as there are no thread cancellations involved, commenting those lines should have no effect. The idea of "session-jobs" looks very interesting. It could be added as a new form of session pool. Could you clarify how would it differ from using a set of single-threaded session pools? > If someone is interested in my modifications to the SingleRTPSessionPool, > I've added a support request where my version of the session pool is attached > (https://savannah.gnu.org/support/index.php?func=detailitem&item_id=105229). > > Any thoughts? > Great patch! Hope to be able to merge this and other support requests soon for a new release! Basically I would say that any pooling/threading/whatever model that reveals useful for a certain application can (and should) be added to the library. _______________________________________________ Ccrtp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
