On Wed, Apr 20, 2011 at 3:18 PM, Koen Deforche <[email protected]> wrote: > Hey Gaetano,
I Koen, I guess you guys have being busy :D > 2011/4/18 Gaetano Mendola <[email protected]>: >> Hi guys, >> due to some critical race in my application using the UpdateLock >> method I converted my application >> to use the Wt::WServer::post. > > Although I would really like to demistify the race condition you had, > I am also happy that you are giving the new post() a try ! Yea I had the race condition for a my own design problem, nothing related to Wt. >> Basicaly what I'm doing is now: >> >> Wt::WServer::instance()->post(theSessionId, >> >> boost::bind(&WtTerminal::swapModel, >> this, >> >> myDataModelBuffer)); >> >> Due the fact the calls are now asynchronus I have to make the object >> instances (this) passed to the >> post to survive the Session, otherwise some posts are called on dead objects. > > In fact, post() will not deliver the event if the session is dead. So, > if you can be sure that the receiving object will exist as long as the > application exists, then you are fine. Unless I am missing what you > are trying to say here ? The instance object I'm talking about is kept alive from other entities that can survive the session. >> So in WtTerminal DTOR I have to wait that all queued posts where >> called or discarded (due >> the session id not found) or that the sessionId is not valid. > > Not really, if the WtTerminal is being deleted together with the > application (in the same 'event') then there is no problem. See above. >> (supposing all the posts are threated in a FIFO policy) and then >> waiting that the method has been > > (Not all posted events will currently be handled FIFO -- this is > something that I would like to fix though) Are, at least the posts for the same session, called in FIFO or not even that is guaranteed? >> It would be usefull if the Wt::WServer::instance()->post(const >> std::string& sessionID, ....) could take two >> function. The first is called if the sessionId exists, the second if >> the sessionId doesn't exist ( I can provide >> a patch for this in case). > > I can see how that would be useful and it solves something that I felt > was lacking with post() (i.e. that events would vanish a black hole!). > Excellent suggestion (and I welcome a patch) ! > > But I don't see how that fixes your use-case? Because if I keep a counter of how many posts are called for each of my instance (decreasing it for each call or for each "not-call") I can know if I have a pending post. > btw.: > - Yes, boost::bind() can bind a shared_ptr. We are doing this in the > built-in httpd. yea I tried my self this morning. > - And yes, finalize() is being called right before the application is > deleted, and while holding the session lock. No more (posted/regular) > events will be delivered to this session. cool. Regards Gaetano -- cpp-today.blogspot.com ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
