[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [Linphone-developers] Bug and bug-pesticide in session_set_selec
From: |
Машкин С В |
Subject: |
Re: Re: [Linphone-developers] Bug and bug-pesticide in session_set_select() of oRTP-0.13.1 (multi-duplex-rtp-sessions problem) |
Date: |
Tue, 27 Nov 2007 15:52:13 +0300 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Re: [Linphone-developers] Bug and bug-pesticide in session_set_select() of oRTP-0.13.1 (multi-duplex-rtp-sessions problem),
Машкин С В <=