Re: [recon-devel] Recon threading model
Hi Julio,
Your analysis of the threading model is correct. There is also some
more info here:
http://www.resiprocate.org/Using_recon#Conversation_Manager_Threading
As for your questions:
> Question 1:
>
> Since you are making extensive use of DumCommand in forward
> APIs, why in recon design you didn´t use DumThread or kept the loop that
> calls dum.process() internal to recon::UserAgent ?
By leaving the calling of process() up to the application the
application can determine if the callbacks will be received on the
same thread as the commands if it wants to. However, I can see that
it may be useful to free applications of this responsibility and to
add the option for UserAgent to be able to spawn it's own thread to
call process().
> Question 2:
>
> There aren't specific query methods in recon API that allow an
> application to learn in real time about current conversations and
> participants. Today the application must cache its own requests and recon
> callbacks in order to keep a "reconstructed" state of Conversations inside
> recon. Or can do as in testUA, method MyConversationManager::displayInfo()
> that I guess is not thread-safe, which is fine for a console demo as testUA
> but not for a general application.
Actually displayInfo, uses "cached" values as you have described.
When a conversation is created it is added to a testUA maintained list
(mConversationHandles). When a conversation is destroyed
(onConversationDestroyed), the handle is removed. Since keyboard
input and callbacks happen on the same thread, this is all
thread-safe.
> Direct query methods are planned for recon ? If yes, what design you intend
> to adopt to warrant thread-safety ? I ask this because in case I need to
> anticipate something like that by myself, I could do it along the lines that
> are being planned.
Nothing is planned for this at this point, since it is fairly trivial
to track the handles at the application layer. In fact it is highly
likely that most applications will need to track the handles
themselves anyway, in order to store some additional application
specific state information. If you want to be able to query the
ConversationManagers internal list of handles from the application,
then you would need to either protect the internal lists/maps and
accessors with Mutex'es, or you would need to implement a new command
and paired new callback in order to return the information.
Scott
2008/12/1 Julio Cabezas <jcabezas@xxxxxxxxxxxxx>:
> Hi all,
>
>
>
> Please correct / comment where needed the following
> understanding of recon:
>
>
>
> In an application using recon we recognize the following layers:
>
> application
>
> recon
>
> dum
>
> stack
>
>
>
>
>
> Threading and communication details are:
>
> stack:
>
> All of stack runs freely in an "internal" thread T1 implemented by
> InterruptableStackThread
>
> dum:
>
> All of dum runs in an application thread T2 that must implement a loop
> which regularly invokes recon::UserAgent::process() that by its turn
> invokes dum::process().
>
> The communication between dum and stack, in both directions, is done
> entirely by means of async messaging using FIFOs, being thread-safe and
> deadlock-free.
>
> recon:
>
> The ConversationManager and UserAgent "forward" APIs run in an application
> thread T3 (app can make or not T3==T2) which invokes forward methods such as
> ConversationManager::CreateConversation() or
> UserAgent::addConversationProfile()
>
> The ConversationManager and UserAgent "callback" APIs run in the thread T2
> used by dum, for methods such as ConversationManager::onConnected()
>
> Thread-safety and deadlock-prevention between T2 and T3 inside recon is
> obtained by use of
>
> DumCommand derived objects and dum.post() in the methods of forward APIs.
> Such command-objects are constructed in T3 and executed in T2.
>
> application:
>
> Implements T2 to give cycles to dum and T3 to acess recon
> forward APIs.
>
>
>
> Question 1:
>
> Since you are making extensive use of DumCommand in forward
> APIs, why in recon design you didn´t use DumThread or kept the loop that
> calls dum.process() internal to recon::UserAgent ?
>
> Question 2:
>
> There aren't specific query methods in recon API that allow an
> application to learn in real time about current conversations and
> participants. Today the application must cache its own requests and recon
> callbacks in order to keep a "reconstructed" state of Conversations inside
> recon. Or can do as in testUA, method MyConversationManager::displayInfo()
> that I guess is not thread-safe, which is fine for a console demo as testUA
> but not for a general application.
>
> Direct query methods are planned for recon ? If yes, what design you intend
> to adopt to warrant thread-safety ? I ask this because in case I need to
> anticipate something like that by myself, I could do it along the lines that
> are being planned.
>
>
>
> Best regards,
>
> Julio.
>
>
>
> _______________________________________________
> recon-devel mailing list
> recon-devel@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/recon-devel/
>