< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Sharing DUM State


If my project, I did it by myself. And I think that should be more flexible, and make the lib simpler. :)

2007/3/1, Nilay Tripathi < nilay.linux@xxxxxxxxx>:
Hi,

If I am getting it correct then I feel atomicity is going to be more relevant in a threaded environment, and for that purpose, yes it should be an atomic operation.

Let me know your thoughts on this !!

Regards,
Nilay


On 3/1/07, qiu michael < antelope.qiu@xxxxxxxxx> wrote:
I need it too. But I think it's a little bit problem. We have to make this handle be atomic.
Do you think so?

2007/3/1, Nilay Tripathi < nilay.linux@xxxxxxxxx>:
Hi,

DUM maintains state for each dialog/session. It is defined in class InviteSession.

What I am curious about is that, is there going to be any problem if we share this
state through the handles? Which precisely means writing a public 'get' function and
pulling out the 'state' enum into 'public'.

I feel this would be a good to have thing, for lets say that I want to integrate this to a
minimalistic call-fsm. This would save from changing into the provided call-fsm and
also need not maintain states separately. Of-course, state transition would not be
allowed but re-usability of DUM states can make life simpler :)

Thanks in advance!!

Regards,
Nilay

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel