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


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.
witty-interest mailing list

Reply via email to