Hey Hadass, 2010/1/14 HADASS YAARI <[email protected]>: > I use to update my dynamic pages with WTimer. I have 3 dynamic pages with > very big tables. > On timer tick I clear the table content and fill in new elements. Apparently > the tables were very big and update time was too long so the browser window > stucked until the refresh.
Out of curiosity: you mean that the application was not responsive for a too long time? Or really that there some kind of timeout? How long did the update last then? > So I decided to change the method to server push. > I have a cyclic thread that emits the signal whenever needed. The pages > register the signal in the Ctr. > the errors are different: > - vector subscript out of range (call stuck: WContainerWidget:: updateDom() > --> server::connection::handleReadyBody()). > - map/set iterator incompatible. > - sometimes a popup appears with : "wt internal error : [object error], code > undefined, description, object required" > > I suppose there is parallel access to a member of the application. > I take the application lock before updating and use triggerUpdate when I > finish. the update contains clearing 2 tables and filling in them with new > elements. I do the same as in the SimpleChat example. > As I wrote last time, I use the same method with the WTimer and it works > fine. Those errors do indicate a concurrency problem indeed. I cannot recall any bug that was fixed since 2.2.3 w.r.t. the update lock, and, the simplechat example never had any issue also with 2.2.3 ? > I also tried to use the WTimer to just emit the signal and it works fine. > This way would have pleased me, but strangely it works slow too - I suppose > that when it emits the signal there is a context switch before the method of > the WTimer returns (maybe because of high priority of handling signal). I'm not sure I understand this: you are using a timer which does not really have any callback associated with it, while still manipulating the application widget state with another thread ? I.e. the server push scenario without server push but with a WTimer ? In that case, yes, the actual rendering will only happen when the timer event is received, and this may be the time consuming step if you have a really big table. > Again, I know it is not very informative, but please think how to guide me > what to do in order to solve it. If you are developing with Linux, you could use valgrind to confirm that indeed you have a corruption because of concurrent access, and it will also show you the stracktraces of the concurrent access. Other than that, I cannot imagine why the UpdateLock would not protect you: it really is a simple lock on the mutex that protects the session which is also used by the WebSession to handle requests. Regards, koen ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
