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
