Re: Re: [Linphone-developers] Bug and bug-pesticide in session_set_select() of oRTP-0.13.1 (multi-duplex-rtp-sessions problem)

[Машкин С В]

Hi,Simon!

Thank you for answers.



### 1 ###



[----- You wrote --------------------------------------------------

Indeed the temp SessionSet is not being reinitialised, thus during the 
session_set_copy, toggled fd from the recv result set may be put into the send 
result set...

------------------------------------------------------------------]



Yes, I see the problem at the same mannere.



[----- You wrote --------------------------------------------------

By duplicating temp into temp1, temp2, temp3, you workaround the bug because 
probably your compiler initialise new stack variables with zeroee, which is not 
the case with all compilers, that's why I prefered solving the bug a bit 
differently by calling session_set_init(&temp) before each set computing. And 

of course it saves a bit of memory. The fix will be on cvs tonight, and in next 
release of course.

------------------------------------------------------------------]



Khm... I have analized your solution...

I am unsure...

But I can't understand,

for what we must call session_set_init(&temp)

before each set computing?



If you'll look into the session_set_and() code, you'll

see, that variable "temp" is output argument of session_set_and().



So, we are not indeed to call session_set_init(&temp) in

parts:

[---------------------------------------------------------

if (recvs!=NULL){

    bits=session_set_and(&sched->r_sessions,

                         sched->all_max,recvs,&temp1);

    if (bits>0){

         ret+=bits;

         /* copy the result set in the given user set */

    }

}

---------------------------------------------------------]



In part below, we copy temp1 only if

recvs!=NULL,

it means, that function session_set_and(&temp1) 

was called before, and so, temp1 was initialisated.



(in cases of sends, errors - the same situation).



[---------------------------------------------------------

if (ret>0){

    if (recvs!=NULL)

        session_set_copy(recvs,&temp1);

    if (sends!=NULL)

        session_set_copy(sends,&temp2);

    if (errors!=NULL)

        session_set_copy(errors,&temp3);



    /* there are set file descriptors, return immediately */

    rtp_scheduler_unlock(sched);

    return ret;

}

---------------------------------------------------------]



May be I am wrong... Without looking on your 

version of "pesticide" I am unsure... Please, public

it on the forum.



### 2 ###



[----- You wrote --------------------------------------------------

- sched->time_: does not need locking. The risk is only that you may have a 
RtpSession not in a recv or send set and need to wait 10 ms more to have it. 

Not a big issue. Anyway changing the mutex_unlock would not fix it, since the 
rtp_session_recvm_with_ts() does not take this mutex to check the value of 
sched->time_.

-------------------------------------------------------------------]



I am not sure, but:



I see, that variable sched->time_ is used in different

threads. And I don't want to be surprized by this potential 

thread-conflict... I think, that it is better to do something

with it, than do nothing. (It seems, that programm, which

is dependent of Moon phases, is not good :-)



It seems, you are right, that moving mutex

locking in sheduler is not enough solution... 



Thanks.



Serf Ma