OK, you guys convinced me, I got rid of all my recursive event loops and now I do have Qt working inside of Wt. Please keep me posted if this issue gets fixed though as it was a non-trivial amount of effort to change all my code this way.
One thing I did trip up on was that in order to get the Qt event loop I was using a QApplication which failed with fastcgi (worked with built-in httpd) because it couldn't connect to X server. Then I switched to QCoreApplication and it worked. An obvious problem in retrospect, but I thought I'd mention it in case anyone else gets tripped up on it. -- Dan On Feb 8, 2010, at 1:15 PM, Wim Dumon wrote: > Hello Daniel, > > Don't forget to increase the amount of threads in your application if > you're using show() intensively. Show() starts a local event loop, and > every session that is waiting in such a local event loop occupies a Wt > thread (Wt needs to keep the stack state somewhere until that local > event loop returns. Normally, i.e. if you're not using local event > loops, there is no stack associated with a session and Wt randomly > assigns threads to handle requests). When all available server threads > are locked by calls to show(), new requests can no longer be handled > and therefore some user's interfaces will lock up until an other users > closes his dialog. > > Calling show() is indeed easy, but it scales not as good. To avoid > lockups at all cost, you must set the number of threads equal to the > maximum number of concurrent sessions you want to handle. It depends > on your situation if this is acceptable. > > You can change the amount of threads in wt_config.xml > > Regards, > Wim. > > 2010/2/8 Ginsburg, Daniel <daniel.ginsb...@childrens.harvard.edu>: >> Hi Koen, >> >> Thanks for the detailed explanation. I suppose I could rewrite my code to >> do things this way. It wouldn't be so bad for a couple of the dialog boxes, >> but I also was relying quite heavily on WMessageBox::show() so replacing all >> of those calls with non-blocking dialogs is going to be pretty painful. I >> am tempted to just ditch Qt until this issue is fixed. I mainly was using >> it for QFileSystemWatcher, but it's beginning to not be worth all the >> trouble. >> >> -- Dan >> >> >> On Feb 8, 2010, at 10:06 AM, Koen Deforche wrote: >> >>> Hey Daniel, >>> >>> 2010/2/8 Ginsburg, Daniel <daniel.ginsb...@childrens.harvard.edu>: >>>> Do you mean to make the dialog non-modal? Or is there some other way to >>>> execute a modal dialog other than using exec()? I would not be able to >>>> make the dialog non-modal, that would not work for my application. If >>>> there is some other way to execute a modal dialog, could you tell me how >>>> to do it? >>> >>> Yes, you can execute a modal dialog without using exec(). >>> >>>> From >>>> http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WDialog.html: >>> >>> WDialog can be used as any other widget. In this case, the WDialog is >>> simply instantiated as another widget. The dialog may be closed by >>> calling accept(), reject() or done() (or connecting a signal to one of >>> these methods). This will hide the dialog and emit the finished() >>> signal, which you then can listen for to process the dialog result and >>> delete the dialog. Unlike other widgets, a dialog does not need to be >>> added to a parent widget, but is hidden by default. You must use the >>> method show() or setHidden(true) to show the dialog. >>> >>> So, instead of exec(), use show(), and listen to the finished() signal >>> instead of inspecting the result of exec(). This does mean that you >>> cannot build your dialog on the stack, and for a complex dialog you >>> will want to specialize WDialog to keep track of form fields. See for >>> example FileEditDialog in TreeViewDragDrop.C (treeview-dragdrop >>> example). >>> >>> In the mean-time we have been brainstorming about solutions to the >>> original problem. One solution would be to not spawn a dedicated >>> thread for each session, but instead make it so that a session is >>> always handled by the same thread (by using a hash function on the >>> session ID which hashes it on a thread from a thread pool). However, >>> we currently do not see how this can be done in conjunction with our >>> current asio design for wthttpd. >>> >>> Regards, >>> koen >>> > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > witty-interest mailing list > witty-interest@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/witty-interest Daniel Ginsburg / email: daniel.ginsb...@childrens.harvard.edu Principal Software Architect Fetal-Neonatal Neuroimaging and Development Science Center Children's Hospital Boston 300 Longwood Avenue Boston, MA 02115 Phone: 857-218-5140 ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
