I suggest you to look at this: http://redmine.webtoolkit.eu/wiki/wt/SimpleChat_made_easy You may modify the code to fit what you need.
2010/4/28 Koen Deforche <[email protected]> > Hey Marcus, > > 2010/4/28, Fleischer Marcus <[email protected]>: > > we are developing a multi-threaded web-application using the Wt Web > > Toolkit; for all multi-threading related purposes, we are using the > > appropriate classes from boost (thread, mutex etc.). Now here is our > > problem: > > > > Usually, you use WApplication::instance() to access the current > > session's application object. In order to let a second thread trigger > > updates, we need to call WApplication::instance()->attachThread() from > > inside the second thread. However, whenever called from within a > > seperate thread, we found WApplication::instance() to return NULL. > > In practice, you will not need attachThread() unless you are doing > something very exotic (I think this should be marked more clearly in > the API). > > What you need to do is grab the application update lock to update the > GUI from another thread. In either case, however, you need to have a > pointer the application which you want to update. > WApplication::instance() uses thread-local data, and this is provided > by the library from within the event loop, whenever a thread grabs an > application's update lock (or from WApplication::attachThread(), > which, you shouldn't be using in this situation). > > For this reason, WApplication::instance()->getUpdateLock() will not > work as expected, since WApplication::instance() is 0 unless you > already have the update lock, and is only correctly set after you > grabbed the updatelock. Therefore, you need to pass the application > instance to the newly created thread which can then use it to grab the > update lock. > > The use for attachThread() (which does nothing more than configure the > thread local data to make WApplication::instance() work as expected > from the new thread), is when you have some other way of knowing that > you already have the session lock, and grabbing the update lock is > thus not necessary to safely modify the GUI state. This is only > possible if you are having your own synchronization mechanism between > Wt's event loop and the additional thread. > > > We may work around this by retrieving the pointer returned from > > WApplication::instance() and pass it to the second thread via > > boost::bind, or any mechanism that stores the actual pointer before the > > creating of the thread. It would also work if the second thread were a > > That is indeed the proper solution. If your thread's main function is a > member > function of the application object, then indeed, you can simply do > 'getUpdateLock()', which kind of hides this complexity related to the > application instance. > > > On a slightly related note, is this also why singleton objects and > > static class members are still individual for each thread? > > Wt does not really use static data, instead it does store a single > object in thread local storage which is accessible through a static > function. > > Regards, > koen > > > ------------------------------------------------------------------------------ > _______________________________________________ > witty-interest mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/witty-interest >
------------------------------------------------------------------------------
_______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
