Re: [Ccrtp-devel] SchedulingTimeout problem

[Federico Montesino Pouzols]

In principle we could, and apart from doubling the number of threads I
see no drawback. The idea is that the run method(s) must execute the
following 4 methods:

                        controlReceptionService();
                        controlTransmissionService();
                        dispatchDataPacket();
                        takeInDataPacket();

and these could be distributed between two threads, in a say
'DualThreadRTPSession' template. In the extreme case you could even
have 4 threads. I'm curious, have you find any scenario where having
just one thread downgrades performance?


On Tue, Nov 23, 2004 at 06:59:57PM +0100, Guillaume Glodas wrote:
> Hi,
> 
> why can't we use to threads : one for receiving packets, one for
> managing scheduled packets sending?
> regards,
> 
> Guillaume Glodas
> 
> Le mar 21/09/2004 à 14:49, Federico Montesino Pouzols a écrit :
> >    Looks interesting, however, the new run method waits for 
> > WAIT_DATA_TIMEOUT.
> > would it block the reception service when there are no outgoing packets? 
> > After a first look I got that impression.
> > 
> > On Tue, Sep 14, 2004 at 01:55:16PM +0200, Guillaume Glodas wrote:
> > > Hi,
> > > 
> > > When there is no data to send, the ccrtp thread waits until
> > > defaultSchedulingTimeout is reached even if data are pushed in the
> > > queue. When defaultSchedulingTimeout is too high it can cause packet to
> > > be sent too late, when defaultSchedulingTimeout is too small it can
> > > increase the load of the computer.
> > > That's why we propose to replace this timeout with a
> > > OutgoingDataQueue::waitData method which waits until the queue is no
> > > more empty or a timeout is reached. It seems to dicrease computer load.
> > > What do you think about this modification?
> > > Regards,
> > > 
> > > Guillaume Glodas
> > > 
> > 
>