Re: [Ccrtp-devel] SingleRTPSessionPool is not thread safe.

[Federico Montesino Pouzols]

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.