Re: SingleRTPSessionPool is not thread safe.

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.